Earlier today there was a bit of a kerfluffer on Twitter about drawers in Mac OS X. Since back-and-forth arguments limited to 140 characters don't do nearly enough justice to the nuance and subtleties of drawers, I want to provide an argument in defense of the drawer.

When Mac OS X 10.0 was first released, drawers were an entirely new UI convention to the Mac. Drawers as a computer interface concept did not exist in Mac OS 9 or in any earlier version of the operating system. (I can't find any evidence that drawers existed on NEXTSTEP, either, but I may be wrong about that.)

Drawers are extensions to windows, providing additional functionality that are often used but are not required to be visible at all times. Conceptually, they work almost exactly as a drawer does in real life. They're attached to something else (i.e.: a desk), and they slide out from underneath the thing to which they are attached. Once you're done using whatever it is you need in the drawer, you can slide it back from whence it came.

Daniel Jalkut of Red Sweater Software, generally argues for the replacement of drawers by other existing UI elements. The split view is one possible replacement that Jalkut offered up. To show why this is an inappropriate replacement, a close consideration of drawers and split views will illuminate the fundamental differences in the UI elements.

First, let's consider the split view. In Leopard Preview, the sidebar provided for multi-page PDFs provides a look at a typical split view:

In Preview, there are two ways to show this sidebar. You can either click a button to open it, or you can choose "Show Sidebar" from the View menu. To close it, you can either click the button or choose the menu item again, or you can simply grab the split view handle (the three bars at the bottom of the window just to the right of the dividing line) and drag it so the sidebar has no width.

On the surface, this functionality is exactly the same as a drawer. You click a button or choose a menu item to show it, and do the same to hide it. You can also drag the outer edge of the drawer to resize it or to close it entirely.

The differences, however, isn't revealed in static screen shots. It's in how each UI element is implemented. Consider screenshots of the Preview window before and after the sidebar is revealed:

Now consider these two screenshots of a drawer being revealed:

There are two absolutely key differences here that need to be understood. First, when revealing a sidebar, you're necessarily cutting into existing content. I'm able to do and see less with the content in Preview's left content pane after I reveal the sidebar. Not so with a drawer. A drawer adds real estate to the existing window, whereas a split view retains the existing dimensions of the window.

The second key difference is related to the first: when you reveal a split view, the existing content gets reflowed in order to accomodate the less space that is now available to that side of the split view. Look again at the before-and-after shots of Preview. Note how the before shot shows exactly one page of the PDF. The after shot shows almost one and a half pages, making the text size about 33% smaller. That content reflowing can mean the difference between being able to read the PDF text comfortably and having to strain your eyes to read it.

With a drawer, again, this is not the case. Since the drawer adds real estate to the window, there's no reflowing necessary.

The implication of content reflowing due to a split view means that getting the window to the desired positioning may be a two-step process: 1) reveal the split view, and then 2) resize the window in order to get the original content back to its original size. In some cases, it may even be a three-step process: resizing the window may also resize the split view in an undesired way: does the left pane retain its size, does the right pane retain its size, or do they both resize proportionally, and is this expected for the user?

Content reflowing is not necessarily undesirable behavior; if you're looking at an image or a series of images (as in iPhoto), it may not matter if things reflow. But it does illustrate how the two UI elements are not interchangeable. For a split view, the expectation is that the current window will be split into two sections, one with the old content and one with the new. For a drawer, the expectation is for a new part of the window to be revealed without disrupting any part of the old window.

One possible counterexample to this is the Finder: when you drag a column's resize handle outside the right side of a window, the Finder window will resize to accomodate the extra space. In this case, though, the user is being explicit that he wants the window to expand laterally. Also, if the user moves the resize handle back to the left, the original size of the window is remembered such that the Finder window doesn't grow smaller as a result of this operation. (By the way, since there are often more than two columns, this isn't a traditional split view anyway.)

Jalkut also suggested using something similar to a Cocoa toolbar. When you reveal the toolbar, the window grows to accomodate the new window functionality. This is closer to drawer functionality but it still disrupts the state of the window in the user's mind. (In some cases where the direction of growth is horizontal, a disclosure triangle is used both to initiate the window growth and to indicate to the user that the window will grow.) The existing content of the window, while it retains its existing size, does not retain its existing location. Whole parts of the window shift down, and certain UI elements have their position drastically altered because of where they must be placed in a window.

If one were to implement a sidebar in this manner, either the resize handle or the close, minimize, and zoom buttons on the window would necessarily have to move, regardless of which of the four sides the sidebar was positioned on the window.

Jalkut correctly observed that there is precedent for this kind of functionality, though. In Safari, when you reveal the status bar or the bookmarks bar or the tab bar or the toolbar, the window resizes down in this manner. (Thankfully, if the Safari window is big enough such that resizing the window would intrude on the Dock, the window actually resizes upwards or doesn't resize at all, depending upon how much space there is.)

Consider, however, if you had an app like iCal, where there are additional buttons along the bottom border of the window. In this case, it would be more than just the resize handle that'd be moved if a sidebar were to grow the size of the window. Is this an acceptable change for the user? For the split view, content gets reflowed; using this solution, it's the window elements that get reflowed.

Another possible replacement for a drawer is simply an inspector window. An inspector window, like the ones in iWork, eliminate the UI issues with reflowing. But this presents a different problem entirely: the controls in the inspector window get disassociated with the main window with which they interact. If you start moving the main window around, the inspector window doesn't follow. Eventually you might lose track of it if you don't use the inspector window often enough.

The point is that a drawer cannot be completely be replaced by any other UI element precisely because it avoids both types of reflowing while still being attached to a window: neither the content nor the window elements of the main window get reflowed when you reveal or close a drawer.

Now, that's not to say that a split view, a view that grows the window size, or an inspector window can't take the place of a drawer. They can, and in some cases it's more appropriate to use these items over a drawer. But the drawer cannot be replaced in all circumstances. It's important to look closely at how the additional functionality will be used before you decide on which UI element to use.

Certainly, there have been many cases where drawers have been used inappropriately, and Apple has been guilty of this in one particularly high-profile app: Mail. Of course, this mistake was rectified a long time ago, with the release of Panther, but it's a good example of when someone gets a bad case of the drawer.

Here's a screenshot of Mail with its now-defunct drawer, the use of which was to allow the user to switch mailboxes:

But the problem here is that switching mailboxes was not something that was just frequently used, it was something that was always used. In my current use of Mail, I always keep the list of mailboxes open, and I did so even with Jaguar Mail. The use of the drawer in this case was inappropriate because it was being used in place of a source list. It's not added functionality, it's necessary functionality. Apple made the same mistake with iCal. The first releases of OmniWeb 5, where the visual tabs were hidden in a sidebar even though they were the primary way of switching between tabs, are another good example.

Why exactly is it bad to use drawers for things that are used all the time? It's not just a case of precedent, it also comes down to how drawers are implemented.

Since drawers are not actually part of the main window, they're just attached to it, they're treated slightly differently. That is, if you drag a window to the side of the screen, a drawer can be completely obscured offscreen. Also, if a window is already too big, "revealing" the drawer doesn't do anything of the sort because it doesn't resize the main window.

If you constantly keep a drawer revealed, it will start to vex you over time, because you'll find yourself resizing the main window just to get the drawer to appear. The nature of the functionality of the drawer gets in the way of what you want to do.

When is a drawer appropriate to use? According to the Leopard Human Interface Guidelines, "[u]se drawers only for controls that need to be accessed fairly frequently but that don't need to be visible all the time," but not "to provide users with a way to navigate hierarchically arranged content in your window" (which would be a source list).

What about some good examples of uses of drawers? The example given in the Leopard HIG is a good one: the build order drawer that is attached to the inspector window in Keynote. For most good presentations, build order is not something that needs to be used because each slide is just displayed all at once. But even if you do alter the build order, you'll likely only use the drawer once per slide. You won't use the drawer often enough to want it displayed all the time, and it needs to be an auxiliary attachement to a window to make sense.

OmniOutliner also uses a drawer to great effectiveness for search results. Searching for stuff in your outline is not something that you'll be using all the time, and as a drawer it's convenient because the search results are specific to a single document: in this case, having a separate search window would be confusing if you had multiple documents open. (Contrast this to how Leopard Preview displays search results: by replacing the navigation sidebar. I believe Preview used a drawer for search results in previous versions of Mac OS X.)

iSquint's drawer is also an example of an appropriate use: most people just want to use the simple interface of iSquint, since they'd be converting it for use on an iPod or Apple TV, in which case there are certain restrictions. But the advanced options drawer is perfect for those who need finer tuning for their video, and it's not frequently used enough to garner a position on the main window.

Sadly, although iSquint's use of the drawer is appropriate, other parts of its interface are not. You can resize the window so that some of the content in the drawer disappears outside of the bounds of the drawer (and even the content in the main window exhibits this behavior). And then iSquint stupidly pops up a dialog whenever you click the button to open the drawer.

How about Transmit? Take a look at this screenshot:

Think about what the Leopard HIG say about using drawers. Which of these three drawers are used appropriately?

The "sidebar" (Panic's terminology, the drawer on the left) is easy: it clearly falls under a way to "navigate hierarchically arranged content" -- it should be a source list integrated into the main window. This presents problems with Transmit's interface because it is already two-paned, but implementing it as a drawer makes things even more confusing because it can affect both panes in the main window.

The transcript drawer (the one at the bottom) is also inappropriate because this isn't something that's frequently used. This is something that's used only when there's a problem with the transfer or a bug in Transmit. This should be a separate window, just like the log for Apple's Installer application.

I'd argue that the preview drawer (at the right) is the only correct use of a drawer in Transmit. It provides access to fairly frequently needed information on files, but it doesn't always need to be visible. Personally, I frown upon using multiple drawers attached to a single window, anyway. It just looks weird, and I think it's an indication that the UI needs to be looked at again.

It's worth noting a few idiosyncrasies of drawers, too. First of all, drawers that, by default, reveal themselves on the left or right side of a window don't always do so. If there's not enough room on the left side of a window to reveal a left-positioned drawer, the drawer will appear on the right side instead if there's enough space. Similarly, right-by-default positioned drawers can appear on the left, too. This is not true for bottom-positioned drawers. (In Interface Builder, you can even set a drawer to reveal itself on the top, but I think that's an incorrect use of a drawer under all conditions and shouldn't even be available as an option.)

This is interesting considering that drawers can also be spring-loaded: if you're considering having a drop area, but don't always want it visible, a drawer is a great option for this. A drawer can be made to automatically reveal itself if a drag is initiated and moved toward where the drawer is. The flexibility of horizontally-positioned drawers makes it even more unlikely that the drop area will be obscured off-screen when the drawer is opened. Jaguar's Mail worked like this: if you dragged a mail message toward the right side of the main Mail window, the mailboxes drawer would reveal itself to the right; if you dragged toward the left side, the drawer would reveal itself to the left.

There's a wild card in all of this: clunkiness. The overall perception of drawers is that they're clunky. Looking at the evolution of Mac OS X, there is clearly a trend away from the use of drawers. I can't think of a single app that ships with Leopard that uses a drawer. I certainly don't use drawers in my own apps that I develop.

But I think the perception of clunkiness isn't due to drawers inherently being bad UI elements, it's because they were being used incorrectly for a long time. Uses of drawers as in Mail contributed to this notion that drawers get in the way. When Mac OS X originally came out (I'm talking about version 10.0 here), drawers were highlighted as a Mac OS X UI innovation and developers seized on them, using them left and right. These incorrect uses of drawers are what caused them to gain the reputation of being clunky.

There's also the weird aspect of drawers that they can have a height (or width) that's different from the main window. Especially for drawers that are positioned on the left or right side of a window, making them significantly shorter than the window itself just looks damn weird. I'm not sure how bad the proliferation of these kinds of drawers are, but it certainly also leads to the perception of clunkiness.

In any case, the scaling back of the use of drawers in the latest version of Mac OS X and the latest apps aren't a testament to drawers not being useful. It's a testament to the limited scope of the applicability of drawers. But drawers are an excellent UI innovation, and I'd be sad to see them go away completely.