The Mac OS X Drawer: A Badly Designed User Interface Element


Computer users must adapt as operating systems evolve. Mac OS X users know just how difficult that adaptation can be. In moving from Mac OS 9 to OS X, not only did the version change from a number to a letter (or Roman numeral, to be precise), but many key interface elements changed, others disappeared, and new ones came into being.

I’m a big fan of most of the improvements Apple made when releasing Mac OS X, and especially the Finder windows in Panther (OS X 10.3). But there’s one user interface element that, if I may say so, gets in my face: the drawer.The idea behind the drawer is both interesting and attractive: it is an optional element that contains additional information, allowing users the choice of whether they want to display this information. But in practice it is an annoyance, since it neither functions correctly nor does it display as it should.

One of the best ways to see how the drawer displays information is in iCal. When you click the Info button at the bottom of the iCal window, the drawer displays, showing information for the selected calendar, or for your to-do list. If your iCal window is too wide for the drawer to display, then the window narrows so you can see the entire drawer. This is good. But when you click the Info button again to hide the drawer, the iCal window retains its narrow size, defeating the user’s choice of having full-screen windows.

Not all applications work this way. As I type this article in BBEdit, I have a document list in the drawer to the right of the main window. But if I close the drawer and expand the window to fill my screen, then click the drawer button, the drawer opens, but the main window doesn’t change size; I cannot see the drawer unless I resize the window. This is very bad. It is not an isolated case either: other applications have the same behavior, and still others don’t even display the drawer if the window is set to full screen. In such cases, you have to first resize the main window then display the drawer.

Yet even this behavior is not present across the board. Apple’s Mail will display the drawer without changing the window width, making it hard to see the drawer’s contents (mailboxes) without manually resizing the main window. And to confuse even more, in some applications (Mail is a prime example), the drawer displays on the side with the most room. Even if you usually have your mailboxes on the left, then move your Mail window enough so there are more pixels on the right side, the drawer containing your mailboxes then displays on the right. In applications like this you can never be sure where this element is going to display; this is a violation of one of the cardinal rules of interface design.

But it gets worse. The drawer also suffers from its very concept as an interface item that is subservient to the main window. In order to highlight this relationship, the drawer’s height is less than that of the main window; in most cases, it runs from the bottom of the title bar to the top of a window’s status bar. The problem with this is that it allows you to see other elements behind the drawer, which can both distract and confuse. Those pixels at the top and bottom of the drawer are just wasted space, and make the drawer seem like an element that is external to the main window, rather than a part of it.

Nisus Writer Express is one of the few applications I know of (I’m sure there are others…) that gets it almost right. (And by this I mean merely that it displays the drawer correctly…) It displays the drawer only on the right side; it moves the main window if necessary to display it; then, when you hide the drawer, it returns the main window to its previous location. In addition, Nisus Writer Express leverages the drawer, allowing users to select which elements it contains: you can choose which palettes you want to appear in the drawer, and you can show and hide them by clicking their disclosure triangles.

Apple should have better considered how users interact with the drawer when introducing this element. It often (and even in Apple’s own programs) looks like a hack. It is inconsistent and confusing, and it’s downright annoying. It’s a good idea gone bad – the ability to display extra interface elements or information in a panel is very useful, but when the display itself is incoherent, it loses its usefulness.

Perhaps what Apple really should examine to see how to display the contents of the drawer is to look at some of its most popular software: iTunes and iPhoto. In iTunes, the source list at the left contains sources and playlists; it can be removed or resized; and it is part of the main window. The same is true for iPhoto. This source list is both logical and easy to understand. Using a similar approach for the contents of the drawer would improve its usefulness.

But Apple is not the only one to blame. If other developers use an interface element that is unsatisfactory, it hinders their own software. No one forces them to use a drawer, though they may think that it is expected of them, since it is a “standard” Mac OS X interface element. Developers and interface designers should not flock like lemmings to bad interface elements; they should use the good and get rid of the bad, so users can get the most out of their software.

Read more articles in this category: Apple & Mac OS X