Wednesday, March 29 Palm got it Right Ten Years Ago. So Why are we Still Suffering?
Ten years ago this week, Palm Computing debuted the Pilot 1000. 1996 seems like eons ago, but the major PDA market has been around for a very short amount of time, really. The primitiveness of that first machine is striking today; but what is even more striking is how the limitations of its hardware made it easier to use. It is a supreme example of constraints leading to superior creativity and execution.
Today even our cellphones have more computing power and graphics capability than those first Palms. In part, I think the relative lack of constraints on our cellphone designers have led them to become sloppy with their design choices, leading to products that are harder, less efficient, and more confusing to use. The designers are not doing their editorial duties. How many clicks, for example, does it take to edit an address book entry on your cellphone?
In the book Information Appliances and Beyond, author Eric Bergman interviews Rob Haitani. Haitani was the software architect at Palm and designed the Pilot’s OS and applications, and then followed Palm founder Jeff Hawkins to Handspring. This is one of the single best essays on UI and experience design that I’ve ever read - I return to it on a regular basis as a refresher. (There are several other excellent essays in this book, I highly recommend it overall. In particular the article about the development of the Psion PDA OS is also outstanding.) I’m going to quote a few things from the Haitani interview here (and hope that Bergman and Haitani don’t mind!).
We assumed we’d reject every feature unless there was a good reason not to. Saving files. Printing. By being merciless, at the end we were left with a very tight core of an operating system.… It all comes back to less is more. That’s because in handheld devices you have constraints that you don’t face with a desktop PC. (p.98)
Jeff [Hawkins] believed we had to make the product considerably smaller than current PDAs. He carved up a piece of wood in his garage and said this is the size he wanted. He’d walk around with this block in his pocket to feel what it was like. I would print up some screenshots as we were developing UI, and he’d hold it and pretend he was entering things, and people thought he was weird. He’d be in a meeting furiously scribbling on this mockup, and people would say, “Uh, Jeff, that’s a piece of wood.” (p.83)
Not enough designers spend time “eating their own dog food” as the expression goes, which partly explains the many confounding choices that lead to poor user experiences in complex gadgets.
On the Zoomer [the failed precursor to the Pilot], our philosphy was that we should put as many applications as possible in to make as many people happy as possible. After it shipped, though, we did some user research that made us question that decision. We found that there were a few applications that people used extensively, and usage very quickly dropped off after that. So we said why burden the product with all this extra functionality if people aren’t going to use it?…. When you’re in Silicon Valley the tech frenzy starts feeding on itself, and you end up losing context of what real people do with real products. (p.86)
To compensate for the slow processor in the Pilot, Haitani tried to strip all operations down to as few steps as possible to speed things up for the user. This caused a lot of arguments.
[S]omeone would say, “That’s just one more tap,” or “That would only take a second.” I would respond that it is analogous to the way you organize your desk in your office, in that you have some things on top of your desk and you have some things in drawers or file cabinets. Why is that? Well, if you look at the things on top of your desk, those are the things you use very frequently and they need to be easily within your grasp; whereas things in your drawer you don’t use as frequently. So I would say, Imagine taking something you use all the time like your mouse or the phone and put it in a drawer. It’s just one extra step to pull it out. But if you use it that frequently, the cumulative effect of that one extra step is excruciatingly annoying. (p.89)
I wish more products today of all kinds followed these guidelines. Our lives would be a lot easier and less complicated as a result. We’ve know these things for a long time now - Palm employed them 10+ years ago, but didn’t invent them all. Why are we still having crappily designed electronic devices foisted on us?Customers ask for features like kids ask for candy. In handheld design, you have to make the trade-offs for them. Robust functionality isn’t a benefit; it’s a cop-out. (p.99)
Design, Technology, User Experience
Reader Comments (8)
Amen to that. It's the same way in graphic design as well. Loading information into an ad or corporate piece makes it too busy, loses the viewer and really is just an excuse not to use real creative copywriting.
On my SONY Z5 it's turning the jog dial, I'm immediately in the Phonebook scrolling down, then one click to select a name and another click to edit it...
Thank you!
Thanks for the encouragement!
I think it's even harder to have this discipline in pure software projects such as yours. The "cost" of including extra features is hidden, unlike in physical products. The cost comes about through development and support time, and of course there is the cost for the user in complexity and time spent learning things that turn out to not be very important.
There is clearly a time and place for "sticking with the basics", perhaps especially on a handheld product such as a PDA which is used in small bursts.
I didn't touch on it in the quotes from Haitani, but there is a countervaling issue of addressing changing needs as people's comfort level and spread of usages change as a product category matures.
An example of this, which Haitani mentions specifically in the book, has to do with mobile email. The dev team thought this would be a sure fire hit. Turns out it went over like a lead balloon. But let's also remember the timeframe: this was over ten years ago, where most people just had a dial up account like AOL, and got 3 emails a day. Mobile email is dramatically different today, which RIM's Blackberry has capitalized on very effectively. Palm (including Hawkins) is playing catch-up on that now. Sometimes the drive for simplicity can stall your evolution.
I think the trick is to map your degree of simplicity to the tenor of the market, and track that as it changes. The problem is that most companies' views on acceptable complexity are way ahead of where the market is at that point. This does not mean that complexity in itself is bad, however, if the particular market you're addressing is OK with it. RIM has increased complexity of functionality in some areas, but scaled it back in others, leaving only a marginal increase overall.
I wrote a bit more about this tension in an earlier post, "It's such a fine line between stupid and clever" in which I discuss Palm and RIM specifically: http://richardsona.squarespace.com/main/2006/1/24/its-such-a-fine-line-between-stupid-and-clever.html
- Adam