Confessions of a User Experience Junkie

Okay, here’s a quick one for the Cocoa folks in the audience. We’ve got this nice convenient function (and several others based on it) for throwing up an alert panel:

NSRunAlertPanel(NSString *title, NSString *msg, NSString *defaultButton, NSString *alternateButton, NSString *otherButton, ...);

Back on NeXTSTEP/OPENSTEP, the first argument was supposed to be a short title (one or two words) that would get put in the title bar, and the second was supposed to the main message in the window. Nowadays, the first argument should be the primary message, and the second should be (optional) additional informative text. But the API declarations and documention still refer to things the old way, so we still see lots of unhelpful alert panels like first one below. The most eye-catching part of the message is the command you just entered — you don’t need to have that repeated at you.

A good alert panel is like second picture. The eye-catching bold part tells you all you need to know in order to make a decision, and the secondary text provides extra information about the available options and their effects. (Also note the button titles: they correspond to actions. If the buttons are “Yes” and “No”, you have to carefully read the question, but if they’re “Save” and “Don’t Save”, you know what they will do.)

Even Apple forgets this guideline of theirs occasionally. (Actually, so have we at Omni. Gotta hunt down and fix all those old alert panels…)

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.

Just in case you’ve found this blog without knowing anything about me (in which case, why are you reading?), I should probably drop a bit of background information for you. Seems like a good way to formally start a blog…

So, um, yeah…

Hi, I’m Rick. For the past four years or so, I’ve had the privilege of being able to take a small role in the evolution of the Macintosh world. For most of the last three years, that role has been as a user experience specialist at The Omni Group.

What’s a “user experience specialist”? It’s the best summary I can come up with for all the things I do here: basically I’ve been involved with just about everything that’s not the meat of our products (or the tofu of our products, considering some of the folks around here) but which is integral to the overall impression a user or customer gets of our work. Mostly I’m involved with human interface design and implementation… figuring out how to best handle this or that feature in usability terms and how to make to look cool, and then pushing the pixels and writing some of the code. (Yes, I’m an engineer. But I pretty much stay away from HTML rendering, automatic diagram layout, and XML outline processing.) I’ve also worked on documentation (print and online), marketing communications, installation and disk images, CD mastering, and pretty much every other facet of where the software meets the user.

Why? The success of the Mac is that its developers “sweat the small stuff”. Apple does their best when they leverage the fact that they, as Jobs says, “make he whole widget”. It’s more than just building the hardware and the software, it’s that they — and other successful Mac developers — take the time to make sure every part of the user experience is simple and positive, starting the minute you open the box. That gestalt experience is what turns contacts into customers and customers into fans.

But it’s a difficult process, with many pitfalls. That’s why I’ve started this weblog — hopefully, sharing some of what I’ve learned will be helpful to others, and the world will be a better place for it. Or I’ll spark some useful debate, and the world will at least be a more interesting place.

Okay, PHPosxom 0.6b1 is up and running, and this blog has a bit of a style to it. Still needs some whacking with a pretty stick, and I’ll have to find a place for that little logo I like to stick on my personal stuff, but it’ll do for now, but it’s not bad for a quick-and-dirty pure-CSS job. Nice thing about doing it this way is I barely have to touch default_flav.php while 0.6 is in progress (which is also why the bottom is devoid of style — it’s not CSS-friendly in the flav file yet).