The Soul of a Macintosh Program

The Double-XX manual contains this choice bit of insightfulness in a chapter called The Soul of a Macintosh Program:

In 1984 Macintosh pioneered a new way for computer programs to interact with the user. No longer (...) is the human user the slave of the computer, responding passively to computer demands (...). Instead the computer sits passively docile with your document shown on the screen pretty much as it will look in the finished output, and the user can freely choose to select and modify any part of it, mostly by clicking and dragging the mouse to directly manipulate the components of the document itself, or else to select any of the available menus to do what the user chooses (even if not related to the document, as in a desk accessory), uncoerced by any computer prompts.

(...) the Mac menus are always there, ready to be selected at any time. If a particular menu selection is totally inappropriate to some context, it is grayed out so it cannot be selected, but it is still there to give the user a comfortable feeling of familiarity. Only when the context is radically changed is the menu bar altered to reflect the new context - but even then the Apple, File, and Edit menus remain friendly landmarks in possibly unfamiliar territory. This is Macintosh, and Double-XX supports the concept fully.

I admit that I'm quoting selectively here, leaving out comparisons to DOS of old to focus on the point I am trying to make. So see this less as a quote, and rather as me re-arranging a few well-crafted words to say something much better than I ever could:

Macintosh applications are there to serve the user. They are here to enable the user, inspire confidence that a particular task can be achieved, and make it easier for the user to actually do it. Even people at Apple these days seem to think that it's OK to show a UIAlert on startup explaining how to use a certain application, others like to show "tips" in alerts whenever the user clicks a button in your app, or to pop up MAAttachedWindows that tell the user what the fifteen different boxes in your window are and what order they need to use them in.

These people are falling for the same misconception that Windows XP had: Put the information in the user's face and users will absorb it. But if you've read Don't Make Me Think! by Steve Krug you'll know that this is not true.

Users want to get work done. When they get lots of text, they scan for information that seems relevant to the task at hand. So keep it short, keep it precise, and rarely interrupt users with modal panels. Save modal panels for important warnings and phrase them in short and concise ways, so the user gets conditioned to read them carefully and heed their warnings.

Okay, so much for the UIAlert, but what about the attached windows? Well, showing them once at startup is not enough. People don't remember everything. If information is not immediately put to use, or doesn't seem relevant at the moment, it tends to get lost. How would a user bring up those windows again? Maybe your app has a menu item, but how would the user know what you're calling these pop-up windows? You and I may know that they're pop-up child windows, but to the user, a window is a grey thing with a traffic light in the upper left. Those aren't. Users don't even know that everything on the screen has to reside in a window. They don't know that attached windows aren't just outgrowths of a window. Nor should they have to know about this implementation detail.

Your UI should strive as much as it can to be self-explanatory. Where that isn't obvious from a control itself, add a label, a well-designed icon, or if you must, a short tool tip with additional information and rephrased words to help disambiguate a double-meaning. Tool tips show up on their own if the user's mouse hovers over something for a while, indicating interest. They're system standard. Users have seen those tiny yellow boxes before, they're likely to try pointing at unknown things. Use two-level tool tips with a hint ("[clover leaf symbol] for more...") if you must provide additional information.

Also, keep in mind that many UIs are not self-explanatory not due to a lack of labeling, but due to an overabundance of it. Keep your main UI simple, and visually set it apart from less important items. Logically group your UI elements, so the user has context to help them in case a label or control on its own is ambiguous. "Hide" items for advanced users in floating panels, helper windows and behind menu items. Take advantage of progressive disclosure. Because often, what people try to fix with pop-up help or labels becomes unnecessary after they've streamlined their user interface.

Reader Comments: (RSS Feed)

No comments yet

Or E-Mail Uli privately.