Nokia’s PureView is the epitome of ‘disruptive technology’

A full-fat version of this piece is now available over at The Verge, I highly recommend that over this slightly hastily-written post.

The Nokia 808 PureView is one of the most exciting phones I’ve used in a long time. So much so that, despite it’s well-detailed flaws, I’m going to be buying one. Unless you’ve had your head in the sand (or perhaps just don’t follow technology news closely) you’ll already know why: its camera.

Nokia’s PureView sensor is a 41-megapixel behemoth which makes the 808 top-heavy, ridiculously thick, and a chore to use. However, It also happens to perform better than any smartphone camera on the market by such a large margin it’s almost upsetting for me to compare the resulting images with Apple and Samsung’s best efforts side-by-side.


A pretty innocuous British pint of beer. Quite a nice shot, I think you’ll agree, but that’s only half (or perhaps a sixth?) of the story.


Zoomed out, you can see the incredible amount of detail the PureView managed to capture from around a foot away. But there’s more detail to be found here.


This is the same photo at 100 percent crop (which means this is a pixel-perfect rendition of what the camera captured).

From Vlad Savov’s review:

I look at the photos I’ve taken with the 808 PureView and keep asking myself, where is the noise? Nokia, what did you do with the noise?

The level of detail Nokia’s sensor offers up is just astounding. That’s what makes the 808 — to quote Stephen Elop, Nokia’s CEO — a truly “memorable” and “disruptive” device. I’m going to put the theatrics to one side now and just throw a ton of photos out there.

The Shard, London’s tallest building:shard

Some more 100 percent crop magic:shardwindows

The Shard’s (not quite complete) peak was over 1,000 feet away from me:shardpeak

Incidentally, while showing off the PureView’s technical achievement, the Shard photo also highlights it’s main weakness — take a look at the cloud to the right and you’ll see it has a disappointingly narrow dynamic range. It’s by no means worse than any other smartphone camera, but its this range, or rather lack of, that distinguishes the PureView from entry-level SLRs that it would otherwise be able to compete with.

We’ve had quite a few requests over at The Verge for some low-light samples from the camera. I thought I’d give a quick demonstration of how the PureView handles extremely low-light situations.


The above image was taken without flash. For comparison, this is what the iPhone 4S managed seconds later:


The 808 PureView has a ton of other tricks up its sleeve: it can record 1080p video and zoom without losing quality, simply by using a far smaller area of the sensor (1080p video consists of approximately 2 megapixels).

You can also use this crop zoom when in eight, four, or two megapixel mode to get much closer to your subject without noticeably affecting image quality. It can also capture beautiful smaller shots by aggregating the contents of up to seven pixels into one, like so:

Click here for full-size 5-megapixel image. This was in a dark room, so utilizes the PureView’s built-in flash.

I think it’s pretty clear by now that Nokia is sitting on a breathtaking advance in smartphone imaging. Unfortunately it has gifted it, at least initially, to a phone that doesn’t deserve it.

So, where does Nokia go from here? There’s little doubt that it’s hard at work integrating one of its sensors into a Windows Phone 8 device, but I find it difficult to see how the company will solve the ergonomic issues it presents. There’s no chance you’ll see the 41-megapixel PureView in even a reasonably-thin phone anytime soon: the sensor is around a 10mm thick without a lens in front of it.

I’m not sure if Nokia can find a way to shrink its process down without degrading image quality. The megapixel count is unimportant, but a smaller sensor would capture less light, which would inevitably result in worse photos. The amount of light you can put on the sensor will always affect image quality, and no amount of technology will ever change that.

Whether someone will have the balls, or the incentive, to try and match Nokia’s effort here is debatable. In my humble opinion, the PureView sensor will be pinnacle of mobile imagery for a long time to come — perhaps forever. And that’s why I have to get it in its raw, initial form

Metro: don’t be afraid to dream a little bigger

Before I begin, let me just say that the images in this article are me roughly representing ideas and concepts — I (debatably) know how to write, not design.

After spending a considerable amount of time with Metro and Windows 8, I’ve grown completely sick of it. The lack of differentiation between apps truly irks me, and I’m growing increasingly concerned with the apparent absence of vision shown in early Windows 8 apps. But Metro is not to blame.

When most people think of Metro, they think of rectangular boxes, Segoe fonts, and not much else. Sure, it looks pretty at first, but after swiping through your 132nd page of rectangles and Segoe, whether you appreciate the design or not, it does lose some of it’s novelty. But it doesn’t have to be that way.

Metro, to me at least, is the idea that pages don’t have to be cluttered with buttons, menus, and unnecessary UI flourishes. Metro, to me, can be whatever you want it to be. As some of you may know, I work for Te Verge, and I’m extremely proud of the site’s design / design team for everything they’re doing. With a growing frustration at Windows 8 applications, very little time, and a modicum of InDesign experience, I decided to mock up a Verge app for Windows 8 tablets. Here it is:


So, what have I done here? Well, I pulled out elements from different parts of The Verge, and made a map of what a Windows 8 app for The Verge should look like. It’s unmistakably Metro; there are four main ‘pages’ which you swipe through horizontally (on an endless loop). Each page, excluding the first, has infinite vertical scrolling.

First is the front, or ‘welcome’ page, which displays whatever is currently in the colorful boxes on our front page, along with a search function, quick links to the forum, and a user area in the bottom left that would show reply notifications in one of our orange icons. The upper portion, which contains the Verge logo and search box, remains on the screen at all times.


On the second page you’ll find our news feed — exactly as you’d see it on our site’s front page — along with the ‘you need to read this’ element (also from our front page) as a persistent column on the right. The third page is a column showing all of our features, and the fourth a similar column showing all our reviews. Pretty simple.


I’ve also toyed with the idea of having the user icon in the bottom left corner as a persistent feature across all pages (tapping on it would expand your comment/post count and forum shortcuts), but i’m not sure that’s really in keeping with the spirit of Metro.


Every single element in the app is straight from the website (aside from the notifications icon and some text headers). With my limited development experience, I feel like pulling in already-existing elements directly from the web, and displaying it natively would be an extremely simple dev task. Perhaps I’m missing something. The only issue I could foresee popping up is Typekit support.


Why do I think this is so great? Well, perhaps I’m biased, but I think with a little work this design could really work. It’s kind of like our website has exploded into easy-to-read/navigate sections, perfect for the smaller screen of a tablet. What I can say with certainty is this: it looks DIFFERENT. That’s important to me, and that’s important to companies. The Verge can keep its unique design identity, just as every other website or app can, while still conforming to the Metro navigational paradigms, which I’m a big fan of.

I think if professionals can dream a little bigger, and break out from the perceived boundaries of Metro, they can create some unique, beautiful, and, most importantly, compelling experiences for Windows 8.

In the interest of not making everyone load huge images I’ve kept the embeds small. If you’d like to play around the original .INDD file / assets, shoot me an email.

Final Disclaimer: this doesn’t mean that we’re making a Metro app, that we’re not making a Metro app, or that this looks anything like our potential possible theoretical Metro app. I’m just a guy that had an hour to fill on a train.

Why is Google maps obscuring what Apple and Nokia’s are happy to show you?

Yesterday I published a short report on Google obscuring military sites in its maps. Since publishing it, I’ve been accused of link-baiting, Google bias (hey, it makes a change from being called an Apple fanboy), spreading FUD, and all manner of other evil activities.

Here’s the full report.

I’d hoped the report would raise some interesting questions. To me it’s an incredibly fascinating subject; what do countries hope to gain by ordering Google and others to pixelate their imagery? Any military worth a damn would surely hide sensitive equipment from their enemies’ spy planes and satellites anyway. And, paraphrasing a commenter, “nothing says ‘hey this is probably worth bombing’ like a pixelated field in the middle of nowhere.”

I wanted to answer a couple of questions in the report. First; “what prompts Google to obscure the sites (and many others throughout the world) in the first place?” and second; *why hasn’t Apple’s satellite image provider been prompted to do the same?“

Google was more than happy to speak with me about its policy, even if the answer it gave, when you consider the facts, was a little unsatisfactory. A spokesperson told me that Google had never had a conversation with officials that resulted in it blurring imagery. However, as Google has access to the same satellite images as Apple (via DigitalGlobe), it looks as though it’s choosing low-res photography for certain sites.

My conclusion regarding Apple (and in part, Nokia, whose maps fall somewhere between the other companies’) was that its Maps app hasn’t really been on the radar of governments, especially considering that, despite a lengthy beta program, the app has only been ‘public’ for a week or so. I closed saying that, as countries take this sort of thing extremely seriously, the company will have to deal with these kind of government requests, and will likely have to start pixelating its maps as well. Unfortunately, Apple didn’t respond to my request for comment.

What I DIDN’T imply, anywhere in the article, was that Apple was enabling terrorists, attempting to incite a war, or being willfully abrasive towards foreign governments. The company is totally new to this market and, apart from a single case in Turkey, I don’t think what it’s doing can even be deemed a serious issue (although I’m sure some agencies will disagree). I think there will be a ton of “leaning” on Apple to change its imagery — behind closed doors of course. I’m pretty sure my article alleviates Apple and Nokia of any blame, as well. The report basically says: “hey, isn’t it interesting that one company has clearly been forced into doing this, but two others haven’t?”

So when people, or indeed other websites, start comparing screenshots of Area 51 (a location completely unobscured on all three services), and shouting that “Google’s maps are actually clearer here!” I can’t help but feel that they’ve missed the point entirely. It would seem, to me at least, that if Google hasn’t pixelated an area then neither Google nor Google’s partners have been asked to pixelate an area, simple as that.

Spotify, app fragmentation, and glass houses

I came across a link to a path post today that criticized Spotify for having two separate apps for iOS 4 & 5 devices in the App Store:

Uh major fail if you have to create different apps for different versions of iOS…

My first reaction was pretty simple: really?

The post was by Michael Potter, who works on Path’s iOS app. Later, he tweeted that “having multiple apps means [Spotify’s developers] aren’t good enough to make it work for all versions,” before pointing out that “Path still actively supports iOS 4 with a single app. It’s called smart engineering.”

Joachim Bengtsson, who works on Spotify’s iOS app, presented the team’s dilemma:

“Trade-off: fix bugs for 95% users VS cut off paying customers VS elegance. Limited resources chose #1 for us.”

At this juncture I’d like to point out that Path’s app supports devices running iOS 4.3 and above.

Spotify for iOS 4 is aimed at iPhone 3G users (stuck on iOS 4.2.something) that either don’t want, or can’t afford, to upgrade their hardware. If Path’s “smartly engineered” app completely ignores pre-3GS devices, why should Spotify’s be expected to do otherwise?

The fact that the Spotify team still makes an effort to support —development has more or less halted aside from bugfixes — the iPhone 3G, is fantastic. Of course, Spotify, unlike Path, is actively selling a service, so it’s in its best interests to keep everyone happy — even if I have trouble believing there are a ton of iPhone 3G users that want to use Spotify.

This isn’t the first time I’ve seen someone take a poke at Spotify’s current dual-app offerings, and I felt compelled to chime in my opinions on the matter. So what was the reply to my support for Spotify’s efforts?

“The point was that a separate app isn’t how you go about supporting old users.”

Apparently, you just shouldn’t bother.

Personally, I’d rather see those of us with modern hardware benefit from the latest features and UI improvements, while users with (relatively) ancient smartphones continue to be able to access the service.

I love Path, I love the Path app, and I’m sure Michael Potter is a lovely guy. We just differ in opinion on this matter.