Confessions of a User Experience Junkie

I’m not sure if I’ve mentioned this here (or in any of the other public forums for my thoughts on UE) before, but I have this general skepticism towards many of the so-called luminaries in my field. There’s the academic HCI experts whose research is of little use outside of their ivory towers, the web journalists who know exactly what they want in an interface and assume it’s the best thing for everybody… and then there’s the folks who did good work twenty years ago but have apparently lost their way since.

One of these made waves in the Mac community this past week… revered HI commentator Bruce “Tog” Tognazzini (founder of Apple’s Human Interface Group) wrote up a review of Mac OS X 10.3 and its interface, after being largely silent on OS X for the past few years. Despite his credentials , Tog’s column reads little differently from the many rants we’ve seen in various online forums and blogs — the ones from longtime Mac “power users” who see any and every change from the OS 9 environment as a crippling blow to everyone’s productivity. He’s got a few good points, but it’s looking like he’s lost his edge and feels the need to resort to sensationalism. There’s an awful lot to criticize about this article — indeed, folks are already ripping it to shreds in some forums — but I’d like to focus on one issue that’s been largely overlooked.

If Tog’s still an expert on anything, it’s the subfield of human interface study that relates to user efficiency; that is, how to optimize a software design so that the user can accomplish the most tasks with the fewest actions in the shortest amount of time. He recognizes that Exposé is a great step forward in this area, and notes the minor time-wasters associated with it (if you use “hot corners”, you have to be careful not to accidentally hit a corner; a problem which could be solved with a tiny delay), and points out several issues of low information density and user slowdowns in the Finder and Dock.

The problem with this argument is that efficiency alone doesn’t make for a good user experience. After all, seasoned Unix command-line jockeys are well known for their ability to accomplish with a few arcane gestures over the keyboard what point-and-click laymen can take a whole day to work though. The whole point of graphical user interfaces is that they balance efficiency with intuitiveness. An intuitive interface may make some tasks take longer to complete than they could in an interface designed for maximum efficiency, but you can learn it on the spot instead of having to take time digging through documentation.

Yes, the Dock takes up more screen space than the OS 9 Apple Menu and Application Menu did. But what we lose in efficiency we make up for in usability: no longer are new users confounded by applications which remain running with no windows open, for example. In fact, the usability advantages of the Dock are making many users more efficient and productive than they were on OS 9 — making favorite applications easily accessible no longer requires an understanding of aliases and a complicated procedure for setting up an hierarchic Apple menu or set of tabbed Finder windows full of them. Also, since the Dock merges these two OS 9 interface elements, users need not concern themselves as much with whether an application is running when they go to activate it.

The best interface designs strive to find a balance between being efficient and being intuitive. Sometimes the one has to be sacrificed for the other, but often, with a lot of work, some inspiration, and maybe a little luck, it’s possible to arrive at a solution that maximizes both.

Apple’s Human Interface Guidelines have long embraced the principle of direct manipulation: when the user handles the icons/text/etc on the screen, she should feel she’s “really” handling the objects they represent. This concept dovetails with that of perceived stability: The onscreen environment should behave as though it conforms to a set of predictable, understandable rules; i.e., the user should generally be able to explain how the screen got to be in its current state just by looking at it. Interfaces which implement these principles are the most transparent — this is one of the reasons why users of the original Finder often didn’t realize they were working with an abstraction.

A lot of little usability bits have been lost in the transition to and evolution of Mac OS X (though not as many as some people think, and more than some other people think); some are difficult to find or to judge, but one that’s quite apparent is the drag-and-drop process. Just implementing drag-and-drop isn’t enough to fully conform to principles of direct manipulation and perceived stability: in order to make the interface truly transparent, what’s going on should be explicitly clear throughout the entire drag operation.

But a number of apps introduce unnecessary abstractions when they generate dragging images (the graphic, often a translucent image or outline, that follows your cursor around as you drag). For example, can you tell which message I’m dragging in this screenshot?

No, it’s not the one about “wonderful russian brides” — you can drag any message, not just the one(s) selected. Mail’s drag image is generic: it doesn’t say anything what you’re dragging, or even how many items you’re dragging.

Consider also these examples from Safari:

If you drag one bookmark, you get a drag image which clearly shows exactly what you’re dragging; but if you drag multiple bookmarks you get an image completely unlike the first, telling you nothing more than “you’re dragging N bookmarks”. (Several other applications work similarly, including iPhoto and Address Book.)

By contrast, the Finder (and numerous other applications) show you exactly what you’re dragging by having the drag image be nearly identical to the static representation(s) of the object(s) being dragged:

You can tell exactly what’s going on in the above screenshots; no matter what happens during the drag operation, the dragging image clearly shows the objects being dragged. This helps to reinforce the notion that the onscreen environment behaves according to principles similar to those which govern the real world: When you pick up an object, you see it being picked up. This aspect of existence is so consistent that we can take it for granted; when objects on the computer screen work the same way, we can apply the same assumptions to them without even thinking about it.

Lame excuses

It could be argued that behavior such as Safari’s is acceptable because in order to drag multiple items you must select multiple items, and this selection is likely to remain visible throughout the drag operation. But that’s not a safe assumption to make in all cases: window ordering can change during a drag, and various types of “spring-loaded” drop targeting may cause the source of a drag to become obscured or hidden by the time you’re finally ready to drop. It could also be argued that dragging is typically a transient state, and thus the user isn’t likely to forget what they’re dragging. But that’s not always the case either: users of trackpads and various other input devices don’t have to keep a button held down in order to maintain a drag, so there’s nothing saying they can’t get up and answer the phone (or whatever) in the middle of a drag.

But even if you brush off the above as edge cases, is there appreciable value to adding further abstraction to your interface? Abstractions of abstractions and metaphors within metaphors can get hard to keep track of. Imagine a library where you’re free to browse the stacks, but when you pull a book from the shelf it’s magically transformed into a card which says, “You’re holding one book”… until you set it down on a desk or the checkout counter, at which point it magically changes back into the book. The real world doesn’t work like that — neither should the computer.

(Don’t read this as a general endorsement of the “everything should look and act just like real-world objects” school of thought — we’ve all seen how spectacularly Microsoft Bob and its ilk have failed. Rather, the idea is that it’s best to keep the number of abstractions in an interface small: “this represents this” is okay, but “this is a placeholder for this which represents this which is a shorthand for this” is to be avoided.)

Developer Considerations

Sometimes bad human interface decisions are made for the sake of ease of implementation. Here’s some pointers to help you stay on the right track when writing your own drag-and-drop code:

• Design your drawing code so you can turn parts on and off and run through it multiple times. In a normal situation you can draw your background, selection highlight, supplemental text, etc. Then when you need to draw into a drag image, set a flag and run through the draw function/method again so it draws only the relevant parts of the items being dragged (e.g. in something like a Finder list view, you want to draw just the icons and titles, not the date modified, size, etc.)
• Cocoa developers using the OmniAppKit framework will find additional methods for drag image control in table and outline views.

One of my favorite things about OS X is how Apple and the developer community have found a way to do application packaging and distribution that encourages good organization. Application “bundles” and disk images solve (or at least improve on) a bunch of problems we had on OS 9 in a way most of us don’t even notice.

In your typical OS 9 applications folder, double-clickable executables were scattered among many folders at various depths of the file system. Sometimes apps were packaged in their own folders even when they didn’t have a bunch of support files going with them — all you’d find in an app’s folder is the stuff it was distributed with (readme’s, release notes, an URL-file or two) which you probably looked at once when you downloaded the app and will never touch again.

Because of this mess of folders, we couldn’t easily use the Finder as a quick-and-easy application launcher the way it was intended, so we created all kinds of tools to fill that role by becoming intermediaries between the user and the file system: folders or popup folders or an Apple menu full of aliases, launchers, task bars, et cetera. Because of issues such as version numbers in folder names, upgrading applications usually required rebuilding whatever aliases or links these launchers used. All this setup and maintenance was difficult for inexperienced users and an annoying waste of time for advanced users.

Thanks to “bundled” applications on OS X, we get a marked improvement on an out-of-the-box system. Before, your average “Mom & Pop” or university computer-lab user only knew how to launch apps that the local computer expert had given them easy access to (and required assistance in digging for anything else). Now an Applications folder full of double-clickable app icons is quickly and easily accessible without needing expert setup — and the Dock provides an option for even-quicker access that even a novice can learn how to customize for themselves.

Of course, this nice organization is just the initial state; the tricky part is maintaining it as new software is added. If we followed the OS 9 pattern but for the addition of bundled apps, new software would come as (after automatic processing) a folder on the desktop, containing not just the app but also a readme and some URLs and other junk you’re probably only ever going to look at once. Instinctively, most users would drag that whole folder to their Applications folder. (Except for the truly novice users who leave the whole mess, plus the .sit and .bin files it came from on their desktops forever.) And after a few iterations of this process we’d end up with file system as disorganized as OS 9′s.

This is where disk images play an ingeniously subtle role. The root directory of your typical disk-image software distribution contains the same stuff yesterday’s folder did (readme’s you’re apt to ignore after reading once and whatnot). But the first point of interaction is the user looking at what’s inside the container, not the user looking at the outside of container — so they’re more likely to, of their own volition, pick and pull our the stuff they want to keep instead of dumping the whole thing on their hard drive and needing to clean it up later. (And thanks to custom window backgrounds, we can provide a prompt so the truly novice users know there’s more to do before the software is fully “installed”.)

So why the long rant about this — after all, OS 9 is dead and gone, and thanks to these changes, the world of OS X is a better place, right? Not quite. For one thing, here’s still a number of products out there using old-style distribution methods… hopefully their developers will notice the trend towards simpler distribution/installations schemes and follow along, but they could probably use some encouragement. For another, even the disk image scheme in its current design isn’t perfect — Apple doesn’t make it all that easy for developers to put together well-built installation images (auto-open, license agreement, etc). And the “disk image file” concept is still difficult for the novice user to wrap their head around (an issue complicated by the fact that so many disk images are distributed as .dmg.sit, .dmg.bin, or even .dmg.tar.gz archives because developers haven’t figured out how to set up their web servers to transmit the proper MIME type for disk image files). There are signs of improvement on the horizon, though (image mounting via HTTP looks like a good step towards working around the concept problem). But we’ve got a way to go…

But at least it’s unique. Well, probably unique, according to some quick Googling.

Speaking of which, my title uniqueness search turned up somebody else’s comments on Apple’s Find File functionality — its author pines for the BeOS search interface of old, where search result windows were exactly like folder windows and could be saved as folder-like desktop icons. Actually, Apple was doing exactly that well before the BeBox hit the streets… it was just part of the Copland project that never saw the light of day (and unfortunately, one of the few Copland innovations that hasn’t surfaced elsewhere at Apple since that project was killed).

Anyhow, I’m still open to title suggestions.