sneJ’s Law of Toolbars
The Pessimistic Form
The set of commands available in a toolbar (even via customization) is restricted to those that are either:
(a) painfully obvious (New, Save, etc.), or
(b) useless to you (Save As EBCDIC, Post To CompuServe, Bilinear Zeta-Regression, etc.)
The Optimistic Form
Combine this with the well-known principle that, while everyone uses only a subset of an application’s features, everyone uses a different subset. Conclusion:
To be useful, a toolbar’s customization UI should allow every single command in the application.
Discussion
There are three difficulties that stand in the way of making every command available in a toolbar:
- Every toolbar item needs an icon. Icons are hard to design, especially for the more unusual commands, and usually require payment to a designer or a stock-icon service.
- Toolbar items need to be enabled/disabled immediately after every user action, as opposed to menu items that only need to be updated when the menus are pulled down. In some cases it’s too expensive to check the status of the command that often (especially during typing.)
- I suspect the OS X “Customize Toolbar…” UI won’t scale well to the number of commands available in a decent-sized app. (I’m not even sure if the sheet even has a maximum height and a scrollbar.) Listing the commands in alphabetical order might be sufficient, though.
[Update, 1:45PM: Clarified the wording a little bit, to make it clear I’m talking about the customization options, not what’s in the toolbar by default.]
February 13th, 2009 at 11:20 AM
I remain to be convinced that an OSX window toolbar differs greatly from the window based menus of Windows. Every command a user requires (at that moment) should be in the Application menus, but to repeat them all in the toolbar seems excessive.
So what is the toolbar for?
February 13th, 2009 at 11:35 AM
It’s a common belief that while everyone uses only a subset of an application’s features, everyone uses a different subset. But is it really [statistically] possible?
February 13th, 2009 at 12:03 PM
I guess the idea of creating a toolbar which covers all commands has already been executed. The result is called MS Office. Obviously once people can have all these commands in their toolbars, they start thinking they _need_ plenty of them as well. The result are screens 50% of which is covered in toolbars and users who just accept that even though it really gets in the way of their work. I have seen that plenty of times.
My guesses to your questions (all of which appear as number 1 in my Safari) would be: 1. Yes, those toolbars will look ugly and their icons will be useless. Countless Windows or Linux applications are a proof of that. 2. Validating toolbar items may take time, but my gut feeling is that this won’t be a problem. 3. Yes, OS X’s toolbar UI will not work for this. It’s already a mess in applications like XCode (there is a scrollbar).
I think the whole argument looks at toolbars in the wrong way. To begin with they should be an additional convenience rather than the main GUI strategy. It may be harder to design apps in a way that they work well without a toolbar, but that extra thought will usually lead to a better design. Secondly they should represent the most common commands. Stuff like back / forward or delete and a few more come to mind. Save as EBCDIC – as amusing as it sounds – doesn’t.
February 13th, 2009 at 2:38 PM
aegidian — Toolbars are for commands that you use often enough to want a quick single-click UI shortcut for, but not so often that you’ve memorized their command keys. The SCM commands in Xcode are a good example, for me — I wanted an easier way to get to them than pulling down the SCM menu, but I had no brain cells left for remembering any extra Xcode key commands.
Or also commands where you know the key equivalent but find a button more convenient. What sparked this post, actually, was wanting to put NetNewsWire’s Next/Prev Tab commands in the toolbar. I can access them with Cmd-Shift-brackets, but when I’m eating breakfast and holding my toast in one hand, those multi-modifier commands are awkward and I’d rather just click a button.
February 13th, 2009 at 2:42 PM
ssp — No, I’m not talking about having every command in the toolbar at once. The OS X toolbar UI is self-limiting that way, as it’s a single row and there are only so many commands that will fit. I’m fine with that. My point was that everyone wants a different subset of commands in that fixed space, and the customization UI in principle allows that, except that developers only toolbar-enable a subset of the commands, and it’s not going to be the right subset for everyone.
As to your point about a toolbar being an additional convenience: That’s correct, and I agree with that; I am talking about convenience in this post. Again, on OS X the toolbar is always a convenience because it’s always possible to hide it, so all commands have to be reachable through the menu bar.
February 13th, 2009 at 3:00 PM
February 13th, 2009 at 3:01 PM
PS: I wish one could preview or edit the comments here.
February 14th, 2009 at 3:17 AM
Jens — I do see your point, but I think that the inherently limited design of the standard Mac toolbar with its space constraints tells you that the setup is not made for arbitrary customisation. If you wanted people to have ‘just the commands they need’ there, you’d want to accomodate people who need a large number of commands as well. By design, OS X’s toolbars come with a ‘designer knows best’ attitude and should encourage the developer to choose wise subset of the commands.
If a user happens to want other commands in the toolbar, the Apple-typical ‘tough luck!’ attitude will come to play. And, as Hendrik points out, that’s probably not the worst thing since most non-technical users don’t even seem to know that toolbars can be customised at all.
BTW, I am not sure the toolbar really is a convenience in all OS X applications, it just should be. Some features will work without the toolbar but aren’t convenient at all (e.g. Find in Preview), others (e.g. Find Message in Mail) simply require the toolbar to be present.