Confessions of a User Experience Junkie

Apple’s tech writers have done a pretty good job so far of rewriting the Human Interface Guidelines for Mac OS X. Instead of yet another addendum to the original (leaving us wondering which older parts are obsolete and which not), the Aqua HIG incorporates many of the universal recommendations of the original while replacing all the truly obsolete stuff with (mostly) concise rules for the current world. It started off pretty meager, but with each revision they’re bringing back more good reading. Kudos.

Unfortunately, there are some major topic areas yet to be covered by the new book. And go figure, the missing parts include the advice many of today’s developers most desperately need to hear. Here’s a sample from the “Human Interface Design and the Development Process” chapter:

During the design process, you may discover problems with your product design. You can use the 80 percent solution to help determine how to solve those problems. The 80 percent solution means that you design meets the needs of at least 80 percent of your users. If you try to design for the 20 percent of your audience who are power users, your design will not be usable by the majority of your users.

Developers are often forced to decide between two approaches to any given HI issue: On the one hand, there’s the design that is easy to work out and implement and whose result is a user experience is close to simple enough that it doesn’t get in the way of a user as experienced as the developer. On the other, there’s the design that may be hard to implement and even harder to plan, but whose result is a user experience smooth enough for Grandma to handle without help. All too often, we choose the former, with excuses the likes of, “That’s not at all difficult once you learn it.” But that’s not good enough for the Mac — the Holy Grail of HI design is the interface so intuitive you don’t have to make any conscious effort to learn it.

In today’s world of Internet-enabled instant feedback and worldwide user communities, this old HIG recommendation has an interesting corollary: Don’t just follow user feedback blindly. See, the users who are active in the Greater Internet Mac Community — the ones who grab the latest stuff on MacUpdate, who run OmniWeb sneakypeeks or Mozilla nightlies, who participate in all sorts of discussion boards to debate which release is “snappier”, who send copious amounts of feedback ranging from “it’d be so cool if it could wax my floors too” to “I can’t stand that it isn’t also a dessert topping” — they’re the ones you hear the most of. But those kinds of users are the experienced ones, and what they want out of your software isn’t always what’s best for everybody.

Okay, this has gotten long, though it’s sort of just the tip of the iceberg. More on this general topic in future updates, I guess.

Yeah, so it’s again been awhile since I updated this blog. I’ve been composing what’s becoming a long essay on software installation/distribution methods… probably gotta cut it down a bit, but first I have to finish it

But I couldn’t help but notice how crazy the installation scheme for one of Apple’s latest software updates is: download the new iPod updater and wonder at the number of layers of packaging you’ll have to tear through in order to actually use the update:

• MacBinary encoding (completely unnecessary if the web server is configured correctly) around…
• a disk image, containing…
• an Installer package, which installs…
• a new folder within /Applications/Utilities, containing…
• a single item, the updater application, which you have to find and run in order to update your iPod

This is ridiculous. The more steps in an unwrap-and-install process, the more difficult it get for novice users, and the more susceptible it is to failure (of the human or machine variety). Not to mention that all the intermediate-stage files are the digital equivalent of fast-food packaging — you’re just going to get rid of them once you get to the goodies inside.

They could have done this much more simply — either a disk image containing the app and docs (perhaps with some prompt included to “double-click this”), or an “internet-enabled” disk image that just dumps the app onto your desktop and then goes away. Why didn’t they?

Okay, here’s a quick one on design principles for the impatient readers out there. : ) Actually, it’s just one design principle. But it’s a pretty important one.

When you present the user with a choice, you force them to make a decision. Choices are generally good, but forcing decisions is bad. And the more choices the user has to make, the more time they spend weighing decisions and the less time they spend actually using your software for its purpose.

If you’ve ever had to deal with a waiter asking too many questions when you haven’t even opened the menu yet, you might recognize this problem. Good software, like a good waiter, lets you think at your own pace and in your own order — and is immediately ready to grant your requests once you’re ready to make them.

And for the love of Woz, don’t force a choice over something trivial. I swear, I’ve seen apps that pop up alert dialogs asking “Do you want me to put an alias to myself in the Dock?”. Thank you… you’ve interrupted my thought process to make me consider an action which, normally, can be done almost without thinking about it.

Must be a common problem… I’ve been asked this a few times now. Most recently at MacNN Forums:

So there’s lots of webspace devoted to application icons, for end users, but my searching has left me empty-handed over where to get good toolbar icons for my app development. Am I going to have to make them myself? … So many toolbar functions are common or at least metaphorically similar.

I think borrowing toolbar icons is good when you’ve got a common function that doesn’t change from app to app, like Delete or Get Info. (You’re welcome to borrow Omni and icons.cx icons in such cases, BTW.)

Be careful, though — using the same icons for similar-but-not-quite-the-same functions can lead to usability problems. For example, in OmniWeb we use different-looking Back/Forward arrows on the browser and on the preferences window because they work differently: the browser buttons take you back through the history of sites you viewed in whatever order you viewed them, but the ones in preferences flip through the panes in a fixed order, like flipping pages in a book. If we used the same icons for both functions, one might be inclined to think they work the same way. Whatever you do, be sure to check out what the Aqua HIG has to say on toolbar icons.

Also, there are a few cases in which toolbar icons are part of the distinctive look or branding of a product. Apple would probably be unhappy if you wrote a mail or mail-like application and used their set of postage-stamp icons for reply, forward, etc. And we’d defend our copyrights if you were to write a browser or browser-like app using our icons for all four main functions (back/forward/reload/stop), because customers come to recognize our product by seeing those icons at the top.

“Borrowing” application or document icons is a different question, though, so I’ll save it for another time.