Source Lists and Drawers
Here’s another UI pet-peeve entry: source lists don’t belong in drawers.…The problem here is that the mailbox (source) list is not secondary to the usability of the product, unless you have only one inbox, no trash, draft or sent boxes, and zero folders! For most users, the source list in this drawer need to be visible all the time, because they’re integral to the workflow of using mail.
2 Comments RSS · Twitter
So, as I see it:
1) What drawers are supposed to be used for would be better in something like a sheet dialog.
2) What drawers are actually used for would be better off in a multi-pane interface or toolbar or tool pallet.
3) The visual appearance of drawers fails to give the impression that they are subsidary parts of another window.
4) Oh, and the behavior and appearance of drawers is massively inconsistent.
M,
I disagree with point 1 because you need to be able to work in the drawer and the parent window simultaneously.
I partially disagree with point 2 because drawers can contain user content, while tool bars/pallettes should not.
A drawer is meant to be for sometimes-used interface elements. It is an alternative to the multi-pane approach (in Cocoa, implemented by NSSplitView), found in Mail, Xcode and elsewhere.
I think drawers should be avoided, unless they fit the situation. I don't see a reason to not have them, just because some designers do not know how to use them properly. Then again, they aren't exactly harmful is used in a situation where a split view would be "better", so why the fuss?
