iphone_braun.jpg
We are all, I think, used to Paul Thurrott rolling out some ludicrous mac-bashing post any time he finds he can’t retain readership. This week he picks on the iPhone’s calculator. Yup. That’s right. The calculator.

Now I’ve used the calculator on my iPhone. I punched in numbers. I punched in operators. I hit the “equals” button. Not only did the calculator respond with a sum, it responded with the correct sum, so I’m not really sure what fault one could find with it.

But I’m not Paul Thurrott. He says, “The iPhone calculator should look like an iPhone application at the very least and ideally offer a number of skins. Obviously.”

Obviously. Geeze. Thurrott’s gotten so formulaic, it’s getting hard to distinguish him from Fake Paul. But in this case I think Real Paul has a point. Well, not really. But I think that looking at the ways in which he is wrong will illuminate some interesting principles of design.

Setting aside the obviously self-contradictory call for the calculator to support both a standard UI and skins, let’s look a little more closely at Thurrott’s claim that the calculator should look like every other iPhone app.

On the surface, this is a perfectly reasonable request. After all, if I were to walk up to 100 random people and shout, “Standard interfaces are good and non-standard interfaces are bad!” I would, more often than not, be considered a wise designer. Standard interfaces are a safe bet, so if you don’t know any better you (like Paul) should claim they are the be-all and end-all of interface design. An end that justifies the means. Something worth throwing both bathwater and babies out for. Because 95% of the time, you’ll be right. It’s that other 5% of the time, though, that separates the real designers from the thoughtless wannabes who blindly follow convention for convention’s sake.

Consider, for example, why standard interfaces are thought to be a Good Thing. By implementing standard interfaces in our applications, we provide our users with a consistent language with which to interact with abstract concepts across many programs. Thanks to menu bars, no one has to worry about how to give commands to functionally different apps. They learn menu bars once, and then can use any program that implements them.

Did you catch the key phrase above? It’s “abstract concepts”. Most applications are rife with abstract concepts. Word processors let you drag and drop text around your document. Spreadsheets let you designate cells that are filled by formulas instead of data entry. None of these operations have real-world equivalents, so users of these applications must learn how to access them. If the interfaces for these abstract tasks are standardized, then users only have to learn them once.

But there are some applications out there that have no abstract concepts. They are modeled wholly on real-world devices that everyone already knows how to use. Imposing interfaces meant to encapsulate abstract concepts on non-abstract applications like this only confuses users.

Imagine we wrote, oh, I don’t know, a calculator application. Let’s say our user has entered a large number into our app and now wants to delete it. The standard interface used to represent the abstract task of deleting input is: select the input you want to delete; press backspace. But no user in the world is going to think of this because they’re not trying to perform an abstract task. They’re trying to perform a very real task that they’ve performed hundreds of times in the real world. They are, in short, looking for the “C” key.

If you keep the needs of the user foremost in your mind and remember what it is that standard interfaces actually do, you’ll realize that the first thing you should do when writing an app modeled after a real-world activity is throw standard interfaces out on their abstract heads. The iPhone’s calculator should not look or behave like other iPhone apps. It should look and behave like a calculator. This is what makes Apple interfaces great and Microsoft interfaces merely usable. Apple is constantly questioning the “rules” of interface design as they apply to specific applications — and always with the user in mind. Microsoft is focused on making everything standard for standard’s sake, as if conformity were a goal in and of itself.

Anyway. Granting that the iPhone’s calculator should look and behave like a calculator, the next question is, “What specific calculator should it look and behave like?” The answer is — forgive me — obvious. It should look and behave like the best calculator ever made.

What’s the best calculator ever made? That’s clearly a very subjective question. But the fact that Apple settled on a 30-year-old german model crated by legendary designer Dieter Rams seems to indicate that it’s a question to which they gave a lot of thought. Unlike Microsoft. And unlike Paul Thurrott.