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

Tweet about this on Twitter0Share on Facebook0Share on Google+0Share on LinkedIn0Email this to someone





45 replies
  1. Anonymous says:

    What a useless article. It’s simply praise for a particular application and a
    series of complaints about other applications. The title is incorrect since you
    are saying that it can be used effectively… it’s not an interface element that
    has to go, it’s one you apparently can’t adjust to. How sad. I’d hate to see
    what happens if you use computers in about 15 years when UI design and
    interface technologies will have advanced again, requiring new UI elements
    and widgets. Perhaps you should boot System 7 back up and see what they
    got right and enlighten us.

    Reply
    • Kirk says:

      First, it is far from praise for a particular app – it’s the only one I know that
      actually makes the drawer serve a purpose, and that displays and hides it
      correctly. Second, if you read the entire piece, you’ll see that I like most of the
      "innovations" in OS X. The drawer is one of the few UI elements that I feel is a
      mistake.

      Can you tell me why you think the drawer is good? From a UI point of view,
      how can you reconcile its quirks and inconsistencies?

      Reply
      • Anonymous says:

        I was very annoyed at the iCal drawer problem as well, until I discovered an
        alternative. When you have the drawer showing, a choice under the Window
        menu becomes available, ‘Detach Info’. Choosing that changes the info
        drawer into a floating window, which I much prefer. To revert to the drawer,
        click the info button, then go to the Window menu and choose ‘Attach Info’.

        I do like the having the drawer in Mail because I leave it open all the time, but
        agree that the smaller size does make you prone to clicking a background
        item accidently.

        Reply
        • Kirk says:

          Yes, iCal is one of the few applications you can do this with. This would be
          great for Mail, for example, to be able to move your mailbox list around in a
          palette…

          Reply
        • Anonymous says:

          I like the way the drawer works in Mail – I leave it closed most of the time.
          Then when I’m dragging messages around, the drawer opens up, I drag
          the messages into a mail box, then the drawer closes again.

          So the mailboxes only show up when I need them. Excellent.

          Reply
      • Anonymous says:

        When not abused a drawer can be highly useful, without having to reconcile
        "quirks & inconsistencies." As stated in the HIG, a drawer’s true purpose is for
        hiding applicable controls that are infrequently accessed. 90% of drawer-
        using apps abuse this and don’t do that, they put frequently accessed source
        lists (like Mail did) into a drawer, which breaks the HIG and becomes the
        source of gripes such as this. I’d list at least one example but I don’t want to
        bring down the wrath of commenters on the poor developers.

        Reply
  2. Anonymous says:

    The previous comment was way harsh. The article is not pining for an old system, it’s suggestions to improve the latest one.One of the things that made Apple special was the consistency and elegant intelligence of the interface. Articles like this that push us back in that direction are good. I hope Apple reads them.

    Reply
    • Anonymous says:

      I would tend to agree with the the comments about the drawer. In
      particular I don’t like the fact that when the drawer is closed, many
      applications don’t go back to the prior width. Another complaint I have
      is that the method for opening and closing the drawer varies. An
      application I like in this respect is Nicecast by Rogue Amoeba. Although
      the labeling isn’t real clear, the operation works great once you figure it
      out. There is a little button in the upper left and right sides of the
      window. Click on the one in the right, and the drawer opens. Click it
      again and it closes. Same is true on the left side. (Although it doesn’t
      address the resizing to fit the screen problem.)

      Reply
  3. Anonymous says:

    Kirk,

    I thought you made some very valid points. The drawer has a lot of
    inconsistencies that make it confusing to use. Mail drives me nuts when the
    drawer, which i always have open, switches sides on me. Omniweb, if I
    remember correctly, does a good job of using the drawer properly. And
    NetNewsWire gets it right too.

    Serioiusly a paned interface isn’t a bad thing. Why doesn’t apple use that for
    Mail’s mailbox’s which I think most power users keep open always. Apple
    really has simple products to use but sometimes they can get too simple for
    people who like/need more control and a little confusing with minor
    inconsistencies.

    Reply
  4. jonhenshaw says:

    The timing of your article is interesting, because Apple is currently revamping the idea of the drawer in Tiger. The best example is with Mail. They’ve basically come to the same conclusion as you have, and have returned to simply adding a column back into the main window (ala outlook). The sad part is that the drawer will not be going away anytime soon. Especially since many developers are just now getting on the drawer bandwagon (like BBEdit).

    Reply
    • Kirk says:

      I’m under NDA with Apple regarding Tiger, so I can’t comment on your
      comment… :-) But if they do renounce on the drawer in Mail, at least, it will
      make the program easier to use. That is actually one of the reasons I don’t
      use Mail (I use Entourage).

      As for other programs, it’s true that the blind adoption of the drawer is not
      making software better or easier to use. BBEdit is a good example – the
      drawer contains a file list (useful), but if you open an FTP browser or terminal
      worksheet, they don’t appear in the drawer, so you need to go to the Window
      menu to switch to them.

      Reply
  5. Anonymous says:

    I Totally Agree – the drawer is useless
    I use Preview a lot(why the hell is it not possible to expand to full screen
    when maximizing with the green button- Who the hell does Apple think it is
    - makeing the desission for me that i can read smaller text than i really can
    do),
    and the drawer disappares out of sight, another idiotic style
    as you mentioned is that it does not integrate to well with the main window
    (too small)

    But You mentioed Iphoto .. as a way to fix this, I come from a MS world, and
    the
    Task Pane used in office – also in Adobe Acrobat 6 Pro i think – surly is the
    way to go-
    When you enable task pane in Office xp the outer edge/line of the app stays
    the
    same, but the inside is rearragend to fit all inc the task pane.

    Apple should leran from MS here- Make the inverse of MS or apple if you
    like- when you turn on
    the drawer the whole applications outer edge would stay the same(same size)
    The
    drawer therefor would expand inwords
    get it .)

    Reply
    • Anonymous says:

      I use Preview a lot(why the hell is it not possible to expand to full screen when maximizing with the green button- Who the hell does Apple think it is – makeing the desission for me that i can read smaller text than i really can do)

      Im not sure what your problem is??
      Hit the Green button to Zoom the window to formatted max height/width (it remembers this from session to session IIRC)
      Now hit the “Zoom In” toolbar button
      The page autoformats itself to display as much height as possible and displays the full width of the page at your chosen zoom level.

      Reply
    • Anonymous says:

      I find the drawer unnecessary in a lot of applications. Often little-used
      preferences/features could be tucked into the preferences section of the
      Application menu with no loss in overall usability of the application.

      re. the "Maximizing windows with the green button" comment.

      Apple has never really had an emphasis on maximizing windows to take up
      all the screen space – even in OS 9 you could toggle between two window
      sizes/states. The idea is that windows can be stacked and multiple windows
      can be displayed at once on your screen, side by side or overlapped. The
      green button merely resizes the window to the most appropriate size for the
      content within it … (this may seem an arbitrary decision at times, but it is
      a FEATURE of the OS, not a fault.)

      It was Microsoft who pushed the concept of taking up all the screen space
      with running applications and using the taskbar to switch between them –
      fine with two applications open, but not with many different applications all
      having multiple windows. With small screen sizes it may seem appropriate to
      use all the screen space to some people, but how ridiculous would this be
      given a 23inch display? ie. Do you really want your application hogging all
      that space when you can put two apps side by side?

      Generally when an application wants to take over my entire screen, I find
      myself looking for ways to shrink it in size so I can access what is
      underneath.

      Reply
      • Kirk says:

        Well, I, for one, don’t have a 23" display. But there are many times when I
        want full-screen windows. I work on a 14" iBook most of the time, so I want
        browser windows as large as possible. Also, when working on text with
        BBEdit, I often need the windows to be wide enough to display entire lines of
        code. (My eyesight is not excellent, and I use fairly large fonts.)

        Add to that the fact that the green zoom button doesn’t always zoom, and
        you’ve got another confusing interface issue…

        Reply
  6. Anonymous says:

    I agree with the article. One of the biggest disasters in OS X is the drawer. As
    implemented by developers, it rarely does what I want and often does what I
    don’t want.

    You could also write an article about the second biggest UI disaster in OS X:
    Sheets. For example, with very small windows, the relative larger size of
    the sheet ends up repositioning the parent window. And you can never see
    what’s in the window under the sheet, the way you can by repositioning a
    dialog box, because the two are permanently attached.

    Reply
    • Anonymous says:

      I’ve disliked sheets since they appeared and have written to Apple several times asking to make them "tear-off-able". Currently the only purpose I can see that they serve is for getting users to deal with errors when the developer doesn’t want the user to see the contents of the app’s window :-) Which obviously is silly (think about it). They are frequently used to ask user for a filename, but hide the content the filename is to be based on… Sheets would be very useful for dealing with errors, etc., *if* Apple would make them tear-off-able by default: they’d force user’s to deal with the error, required input, etc., but still allow them users to move them if they had to.

      As for drawers: before completely dismissing them, try this: drawers differ from palettes in that they are attached to the application. It can be confusing to (mentally) associate palettes with particular applications if you have several applications open. By contrast with drawers, its easy to find "mine host" and vice versa, the find the GUI elements belonging to the current app.

      So, a challenge, before dismissing drawers – suggest an alternative that would make clear the application – GUI element relationship, yet allow the controls be placed on the main window. (Some kind of docking arrangement for palettes?)

      Reply
      • Anonymous says:

        Can’t tear off sheets without breaking the principle of linking the sheet firmly
        to a window–necessary since applications’ windows can now be interleaved
        in OS X.

        How about a transparency slider in sheets? That would solve it obscuring the
        window below.

        Reply
        • Anonymous says:

          Transparency isn’t an entirely bad idea, but it’d be confusing if there was enough material in the sheet conflicting with what’s behind it.

          I still believe Apple should make sheet tear-off-able as the default behaviour, with "fixed" sheet to be explicitly asked for in the rare instances its genuinely its useful.

          FWIW, I now remember at least one good use of sheets I’ve seen – when asking for passwords, as in Apple’s installer, etc. Its one case where its a valid notion to hide the contents of the window while the user deals with the request in the sheet. In this case the developer would want to set that the sheet remain fixed.

          Sheets don’t have to be /physically/ tied to a window – they could always hold the focus while that window is open, regardless of where they are (end up) located in the way that dialog boxes (can) do. Its essentially what sheets do – force the user to focus on the contents of the sheet. They should start out as the currently are – its gets the user’s focus – but subsequently be allowe to be moved with the caveat that they hold the focus for the window (or application). I see no reason this can’t be implemented, window interleaving notwithstanding; all that has to happen is that if a window has a sheet open, and the window has focus, the sheet must be in front layer and hold the focus.

          (They might be other issues, like attempts to drag items to windows with sheet open, but it seems to me that these issues already exist.)

          Implemented this way, sheets initially get the user’s attention, as they should, but allow the user to manually move them (keeping focus) if need be.

          Reply
          • Anonymous says:

            I think sheets are one of the best interface innovations introduced with OS X. When running many windows, it clearly links a message to which document window it refers to. In the case of saving a file, an open sheet attached to a window makes it clear that you can’t change the contents of the window without deciding to save or cancel it (prevents confusing state mismatches) If you were editing 6 documents, a window with a sheet can be moved/minimized to deal with later, without forgetting which window has the dialogue attached and trying to click on the window. More transparency is an interesting option.

            I generally agree with the criticism on overuse of drawers. Add the fact that properly written palettes disappear when their windows lose focus to reduce clutter, and drawers don’t.

            Reply
        • Anonymous says:

          How about sliding the sheet up instead of down on small windows?

          I like sheets, I like that you can have several windows with their own dialog
          tied to them…

          And I like drawers too… they impress your windows/linux friends (and they
          don’t need to know they’re not so well designed, do they?)

          Reply
      • Anonymous says:

        The intended purpose of sheets is as a replacement for modal dialogs, to make it obvious which window’s input is being blocked by the sheet. The problem is that some developers (including those within Apple sometimes) feel that they should use drawers and sheets or their program won’t be OS X’y enough if they don’t make use of them.

        I like the fact that there’s no question which app a sheet is attached to, and it pays to bear in mind that since the program has stopped processing input when it displays a sheet, there would be little use in having access to the information underneath it anyway, since it’s not possible to scroll a window when it’s no longer processing information, waiting for the sheet to be cleared.

        Please tell me one occasion when an old modal dialog box would be better, I can’t think of any time that I couldn’t just dismiss the sheet, grab the information I needed, and then recall the sheet again. If it were a modal dialog, I still probably couldn’t copy/paste the information even if I could see it, which is IMO even more annoying.

        Reply
        • Anonymous says:

          I’ll let you read my reply to another post above first – you’ve slightly missed my aim. I’m not suggesting losing sheets: I’m suggesting that they be allowed to be moved from their initial position if their position turns out to hinder the user from completing the task.

          Also, remember that good design for a series of steps involves avoiding forcing the the users to have to take backward steps – you might be an exception, but most users get sick of having to go backwards all the time very quickly!

          (If it helps it occurs to me that you might make a valid case that if that window with a sheet open is hidden or the focus shifts, the sheet re-attaches. You only need to move the sheet to complete the task without taking a backward step, so it need only move while the user is active on that task. Put another way, you could argue that you can only move sheets while that window currently has the focus. This would leave only one "floating" sheet – the one for the top-most window – and the other points you raised would still be true.)

          Reply
      • Anonymous says:

        It can be confusing to (mentally) associate palettes with particular applications if you have several applications open.

        Most apps, at least the well-behaved ones, hide their palettes when the app is not in the foreground. So I don’t see how this is an issue.

        Reply
      • Anonymous says:

        How in the hell do you dismiss sheets as a bad UI feature then praise drawers
        for the relationship they imply between the contents of the drawer and the
        window they’re attached to? That’s precisely what sheets do!

        As for sheets being so large that they obscure the window, how small do you
        have your windows set? A typical "You haven’t saved this document, do you
        want to save it?" dialog is pretty small, and unless you have purposefully
        expanded the file browser in the "Save as" dialog, it’s no bigger. Sheets do an
        excellent job of unmistakably linking a dialog to a particular window.

        Reply
      • Linda says:

        Regarding the drawer as a replacement for palettes? I don’t see it. I don’t get confused by "which palettes go with which app" — because only the palettes for the foremost app are visible on screen. When Photoshop is foremost, only its palettes display; when I switch to Illustrator, PShop goes away; when I switch to XPress, the Adobe apps hide their palettes and only the XPress palettes appear. <shrug> Maybe I’m not using the right apps to have palette wars?

        Reply
  7. Anonymous says:

    Maybe it’s a matter of taste, but I prefer drawers to act like they do now
    because it’s intuitive. Unless the developer takes steps to change the default
    behavior a drawer will open on whichever side has room enough to display it.
    If opening makes part of the drawer slide off-screen, that will happen.

    Contrast that to what the author would like to see – opening a drawer causes
    your application window to jump around, possibly obscuring other
    applications or parts of the desktop you may need to see. Since you don’t
    know how wide the drawer is, you don’t know how much of your desktop real
    estate is going to be monopolized.

    The only thing that makes drawer behavior inconsistent is developers who try
    to compensate for their "shortcomings" by programming this kind of lunacy
    into their applications. You cannot blame Apple for this. The HIG is clear on
    how a drawer should be used and the implementation itself is consistent.

    Reply
  8. Anonymous says:

    My biggest problem with drawers is that frequently, the information displayed
    in them is vital to the smooth usage of the host program. This necessitates
    leaving the drawer open all the time, thus defeating the purpose.

    Reply
  9. Anonymous says:

    Drawers, I believe, have their place. They fit in the spot between a floating
    palette and a modal dialog (sheets). There are times when the user will
    possibly need to take action, however, they do not need to be interrupted
    from their main work flow.

    Palettes work well in some regards, but honestly, I find them more annoying
    than helpful. I am always moving them out of the way due to the ‘active’
    document below. And sheets, as with most dialogs, need to be dealt with
    before continuing (sheets are not app modal, but they are window modal
    which disrupts the workflow.

    I have used drawers in an application. First, the users "can" connect to a
    server, but are not required to operate the system. So I placed the
    ‘connection’ mechanism (which lists available servers) in a drawer. They can
    open it when they want to connect … but for 95% of the time (both when
    connected and disconnected) they don’t have to be looking at it. And since
    the connection is directly associated to the window (it is a multi-window app
    - multiple connections allowed) opening a secondary window or dialog did
    not make as much sense.

    So … there is a place for it. It is up to the developer to do it correctly. Let the
    developer decide placement (LEFT or RIGHT or BOTH), to auto-resize the
    window and/or move the window. And … if the developer does it properly,
    replace the window when your done. Power is in the developers hands … but
    it is a useful tool, just not necessarily in applications like Mail.

    Reply
  10. Anonymous says:

    Hey, I LIKE drawers, case in point: MacJournal vs Ulysses: which has the more
    elegant interface? Its MacJournal. Those wasted pixels do a lot to make an
    app look a lot sleeker.

    Reply
    • Anonymous says:

      Both of MacJournal’s drawers work perfectly. When you open either drawer, the main window resizes (if necessary) to fit both the window and the drawer onto the screen. When you close the drawer again, the window returns to its original size. The same is true when you open and close both drawers. Of course the "journals" drawer is indispensable (in a good way) in MacJournal, so I never close it. As for the vast majority of other OS X applications, the drawer concept is a complete waste of time (in an annoying way). These programs are nearly useless without the items that are in the drawers (such as all mailboxes in Mail). That is sort of like having a place to hide the steering wheel in your car while you are driving somewhere. – Welfl

      Reply
    • Kirk says:

      But MacJournal puts essential stuff in the drawer – which is one thing that it
      shouldn’t do. Ulysses, it’s true, needs to provide a user option to "close" or
      remove the side panels. You don’t always want them visible, and they are not
      totally resizable.

      Reply
  11. Anonymous says:

    Yeah, I know, but I wish there was a goodUI out there. I still haven’t found what I’m looking for.

    Looking for “classic Mac OS”-like simplicity, but completely programmable/customizable. (Lisp/Scheme would be a plus.)

    Reply
  12. Anonymous says:

    I agree with the articles critics on drawers. I’ve never liked them, they allways seem like a hack, an unfinished part of the application. When I uppgraded to BBEdit I’ve read about the drawer and I used it alot at first, thinking this was good. But then I realized that it wasn’t good at all (for example I couldn’t use "Exchange with Next" command). Going back to my previously way of working with windows in BBEdit, using the Windows palette, was much more effective.

    Reply
    • Kirk says:

      My feelings exactly. At first, I thought it was a good way to work with BBEdit,
      since I often have multiple documents open. But the Windows palette also
      shows FTP browsers and shell worksheets, making it much more practical.

      This said, it’s possible that BBEdit updates the program to include these items
      in the drawer.

      Reply
  13. Peter says:

    One of the WORST interface elements I find is the "Sheets"
    - OK sometimes it’s OK,

    But when File => "Save As" – It hides what I am trying to save.

    Often I want to use some content to decide the filename
    to I have to cancel, decide the file name then choose Save As again,
    then type the file name.

    I find this awkward – I would prefer the Save As dialog not to obscure the
    content so much. Yet the clear association of this dialogue with the file is an
    asset.

    Reply
  14. Anonymous says:

    The problem is that some developers (including those within Apple
    sometimes) feel that they should use drawers and sheets or their program
    won’t be OS X’y enough if they don’t make use of them.

    Oh god. The real problem are the irritating Mac fanboys who will
    denigrate an otherwise excellent Mac app only because it doesn’t use sheets
    or drawers. Like it’s not enough of a “real Mac app.” It’s this kind of
    puritannical, cultish prejudice that makes Mac users look bad, and they are
    the people who will implement drawers and sheets without understanding
    what they’re really for.

    This thread, by the way, is a good discussion on what drawers and sheets
    are really for. Thanks.

    Reply
  15. Anonymous says:

    …And everyone else on his ‘side.’

    It feels great to find what you’ve been feeling for long, *accurately reflected*
    in an article and other people’s opinions.

    I believe the Finder/iTunes/iPhoto solution is the best – yet imperfect…
    Why they won’t get it right, is a mystery to me – Btw, it could easily be
    implemented with all the pros of a drawer, but without its cons. So why mess
    around?!

    I wish Apple listened!

    Alberto – A Spaniard in Glasgow, Scotland.

    Reply
  16. jhaffner says:

    Just a short gripe. I don’t mind the drawers as much as I mind that they are generally not accesible via the keyboard.

    This is especially annoying in Mail.app. I really miss the ability to navigate through the list of mailboxes via arrow, tab, or even first letter (ala Eudora’s mailbox window). It wouldn’t be so bad if mailboxes were a ‘nice-to-have’ feature of the application — but it really is essential to be able to move around your list of mailboxes!

    Best Regards,

    John Haffner


    Don’t worry, it’s out of control.

    Reply
  17. Anonymous says:

    The trouble with Drawers is not with the Drawer itself it’s with the API. The developers have a bit too much freedom to screw up the drawer implementation. At the same time, I am a developer and I love options and flexibility. It is a catch-23. It is the developers responsibility to implement the drawer properly.

    The evidence is in the different applications and how their Drawers behave differently.

    Reply
  18. Anonymous says:

    How does a man who complains about wasted space end up writing on his
    site that narrows replies. One vicious thread with replies to replies, and on
    and on would make comments pretty narrow, but I am sure this will be
    solvedif it ever becomes an issue. Oh wait! Maybe the software engineers at
    Apple will make changes to their apps. Maybe the HIG will change.

    What Kirk never did, which seems sloppier to me than a drawer drawn off the
    right sideof the screen, is address the core issue raised by his thesis: Is it the
    design or the implementation that is at issue? The iCal example suggests that
    it i an implementation issue. If that is the case, the problem is not with
    drawers but with designers.

    By the way, have you noticed how much horizontal real estate most Mac users
    have these days? Cinema displays and Powerbooks make the space used for
    drawers all but irrelevant.

    Reply
    • Kirk says:

      I’m afraid the "cinema display" question is an easy way out. I don’t have one,
      and I don’t know many people who do. So you’re saying that the software is
      designed only for those who can afford the best hardware? That’s not how
      you design software.

      Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply