How hard is it to design a button?

I reviewed the PRADA Phone by LG 3.0 for the Verge this week and discovered that LG is as incapable of designing a power button as it is naming its products.

The first issue that crops up is the sleep / wake button — it’s simply in the wrong place. Unlike some of my contemporaries, I can deal with a top-mounted button on a large-screened phone, but LG has placed it so close to the right edge of the device that even my piano-playing fingers couldn’t contort round to activate it. When I approached the button from the rear, the beautiful angles of the rear cover became a barrier that prevented my finger from reaching it. I’m going to start a petition to have this button become the official definition of “form over function.”

How did this design made it past a render, let alone through the prototyping phase?

I don’t claim to have a clue about the intricacies of product design. I’m strictly an end user, but I know when something does and doesn’t work. I don’t understand the difficulty in manufacturing a good button. The market is littered with phones that suffer from issues, whether it be a lack of travel, “squidgy” texture, or poor placement, very few products seem to get it spot on.

My colleague Vlad Savov wrote of the Lumia 800:

The volume rocker and lock button sit too close to one another and are almost flush with the phone’s side, making for difficult tactile recognition. They’re also a bit loose and generate an innocuous, though irritating, rattle when you move the 800 around.

The Lumia 800 is a breathtaking piece of design, so why the lack of attention to detail? I can understand that a design team may be too close to to a device to find issues, but why wasn’t this flagged up in testing? Is it simply a matter of companies not noticing these issues, or is it just that they’re incapable of rectifying them?

Despite the nonsense about design similarities — I’ve yet to find a designer that thinks the Galaxy S II looks similar to any iPhone — Apple and Samsung have very different ideas when it comes to materials, button placement, and user experience in general. But both companies consistently put out products free of button and build issues. Is it coincidence that the pair are also the manufacturers of the top two smartphones on the market?

Everyone cares about design, whether they know it or not. When handling a phone they’re imperceptibly judging the design not only by looking at it, but by holding it in their hands, touching the screen, and yes, pressing the buttons.

Physical buttons are the first and last interaction points with any phone, and the importance of getting them right shouldn’t be underplayed.

The stock Android gallery app is storing lists of full addresses unencrypted

This is a labor of love. Hope you like it.Clarification in reply to comments on the article:

“One thing that quite a few commenters don’t seem to appreciate: There were no photos on my device. The street addresses listed were from Picasa Web Albums marked as ‘private.’ They were synced at one point, but had been removed at least a week prior to the discovery. This isn’t data that could be gathered even if someone had my device in their hands, and a ton of time. Not without the chunk_0 file, at least.”

One man wants to end viral infections once and for all… by making them commit suicide

I wish I had something insightful to say about this, but Jesse Hicks is just the god of original reporting.

Read this. Then, click his byline, read everything he’s written for The Verge, and be amazed.

The Random Adventures of Brandon Generator

I just read Jamie Keene’s excellent article on Brandon Generator, a crowd-sourced story project by Edgar Wright and Tommy Lee Edwards.

It’s a film noir-inspired story written by Edgar Wright — the man behind Shaun of the Dead, Hot Fuzz, Scott Pilgrim vs. the World, and Spaced — that follows the story of Brandon Generator, a comic book artist with a terrible case of writer’s block. The artwork comes from illustrator Tommy Lee Edwards, famous for his work on the Batman, Hellboy, and Marvel 1985 comics. Narration comes courtesy of Julian Barratt, one half of The Mighty Boosh.

The first episode sets up the premise perfectly. Brandon is a struggling, tortured writer who spends his days with his Nespresso machine and a blank laptop screen. On drinking his 13th espresso of the day, he blacks out. After waking, he’s shocked to find text on his laptop, drawings on his sketchpad, and messages on his dictaphone. Turns out he wasn’t completely asleep.. or was he?

As the episode ends, you’re invited to take a look around Brandon’s room, and that’s where the game begins. Wright wants you, the reader, to leave text, sketches, and voice recordings that will help shape the story that will be in the next episode.

Wright already has the story arc planned out — but it’s down to you to provide the details

Forget the tie-in with Microsoft on this project, it’s just a lot of fun.

How to work across three devices, seamlessly

If you haven’t found it by yourself already, Paul Miller’s Verge at Work feature on managing ideas is an enlightening read. There’s a great little video that accompanies the article as well.

My ultimate concept here is that whenever I have an idea, I can easily record it, and whenever I want to write I have easy access to my ideas.


I tend to write directly into a CMS, occasionally falling back on TextEdit, or using Google Docs for collaborative projects. Miller’s article makes me feel dumb. There are times when I feel chained to my laptop — if I’m writing something longer than a few hundred words, I’d like to be able to step away, review what I’ve written and work out what needs to be changed or reworked. I simply don’t have that flexibility using a CMS, GDocs, or any single text editing service.

The Miller method is ridiculously simple. One app, Simplenote, to note ideas on his iPhone; another app, Notational Velocity, to manage and expand those ideas when on the Mac; and an iPad app, Plaintext, to comfortably review and make copy edits.

The apps sync with each other, behaving like one, seamless writing experience. The system is held together by Simplenote’s backend, with a few missing ends tied up by Dropbox. The genius at work here is the freedom of it all — Miller also highlights other apps that he uses, which all fit into his system without the need for any major changes.

At some point since Google Docs freed us from Word and Pages, this revolution happened, and I missed it. I can now have my pick from a large group of applications, and have them all play nice. Perhaps i’m just behind the times, but that’s a beautiful thought.

This was written entirely in a CMS. I didn’t learn a thing.

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

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.