Why Toolbars are the Wrong Tool for the Job
This is the second in a series on what’s gone wrong with pulldown menus and toolbars. Last time in the course of discussing vaguely named and poorly organized menus, and I mentioned how the clutter of toolbars also interferes with menubar usage. But that may make you ask, “Well, as long as users can do the important things through the toolbars, who cares what happens to the menubar?” And indeed, as I described in my last article on menus, the toolbars have become the primary means of activating a command in most applications, not just for experienced users, but for novices as well, owing at least partially to the way users learn to use computers. Designers appear to have recognized that toolbars are becoming the way to do things from the get-go. The toolbar in MS Internet Explorer and later Firefox include a toolbar that is less a set of shortcuts for experts than it is the general-use menu for all users. Browser-loaded applications like Hotmail’s email composing page and Acrobat provide toolbars as the only way to carry out commands, such as Find and text formating. Novice users who cut their teeth on interacting with the web are being reinforced on the notion that the toolbar is the only proper way to make a command. We seem to have a cycle of users using toolbars more which leads designers to put more functionality on toolbars, which encourages users to use toolbars more. It looks like Internet Explorer 7 has taken this to its logical conclusion and completely hidden the pulldown menu in favor of the toolbar. Take a look a look at Office 12’s new Ribbon, and recognize it for what it is: tabbed toolbars.
That would be fine, except for one thing: toolbars, as they have evolved, frankly suck.
“Toolbar”
Lets start with terminology. What kind of name is “toolbar”? “Bar” I understand, but “tool”? First of all, the metaphor is completely off. In the physical world, a tool is an object, something you pick up and apply to another object to accomplish a task. However, most of the items on a toolbar, such as Save or Copy, carry out an action immediately on activation, just like any other menu item, and most un-tool-like. Yet for some reason View – Toolbars > is suppose to mean something to users. I guess everyone realizes the tool metaphor is inappropriate because, while users, trainers, and documentation call the container a “toolbar,” usually they call the things within “icons.” Having icons on your toolbar makes as much sense as having wallpaper on your desktop. Calling them “icons” fuels confusion with real icons, those pictures that represent objects like windows or files, not actions like Save or Copy. No wonder novice users never know to click or double click an icon. To a user, a little picture is a little picture.
“Toolbar” used to make sense if you think back to the first toolbars. In the earliest toolbars, clicking on a “tool” almost never executed an action on its own –it changed your pointer and then you had to click or drag on something else in order to execute an action. These toolbars were actually small utility windows in early drawing programs and other apps, where the icons within really were like physical tools. They were objects you “picked up” and applied. Want to erase something on your page? Pick up the right tool (click on the eraser) and apply it (drag it over over the thing to erase). A perfectly good application of metaphor. But then along came MS Word 1.0, where the designers took the idea of tools and decided to use it for shortcuts to commands, like setting the style of text. And, it worked well, and others started copying it, and it just took off from there. So today we tell users to click on the “icon” on the “toolbar.”
Whatever the history, the solution is to adopt more apt labels in our documentation. “Quick Access Menu” and “Quick Access Items” might be better. Unfortunately, this is one of those things that only works if we can all agree on the terms to use.
A Word is Worth a Thousand Pictures
History is also the main reason why we use little pictures to label our toolbar items. That practice is by far the stupidest thing about toolbars, if not about modern GUIs in their totality. Can you think of anything worse to label an action than a picture? What hope do you have of recognizably illustrating a process in just 16×16 pixels? None. Zip. Give up on it.
Pictures make good labels for objects, like a file folder or an eraser, at least as long as there is a decent metaphor from the physical world to apply. It’s easy for a picture to represent a concrete thing. You make a picture of… the concrete thing (but try making distinct icons for something more abstract, say, an invoice versus a payment). Pictures also can make good labels for attributes values, at least as long as they are visual attritbutes, like Bold Text or Double Space. This can work because you just need to show something with the attribute value you wish to represent. That’s why Word’s original toolbar was so successful. It wasn’t so much a toolbar in the present sense of a bunch of command shortcuts as a properties bar of editable attribute values for the current text. That was a great thing to have, and a substantial improvement over the older feature of its competitor, Wordperfect, with its Reveal Codes view. But that wasn’t the lesson designers learned.
The first problem with using pictorial labels in the toolbar is the size. The picture has to be small in order for the toolbar to be space efficient, a problem a pulldown menu does not have to contend with. As anyone who has tried to make intuitive icons knows, making anything recognizable at a casual glance in that small space is remarkably challenging. One user I know thought the Save icon was supposed to be a TV. I’ve been using the Word Review toolbar for years and only recently realized that the Track Changes icon was not supposed to represent a shiny new Rosetta Stone, but a pencil in front of a red-text document. If users can’t even tell what the picture is supposed to be, what hope do they have of guess the action to associate with it?
Assuming your users actually recognize the image, going from image of an object to action is remarkably impossible. You’re trying to represent a verb with a noun. It’s too big of a leap. For example, take a good critical look at the standard toolbar icons. The only reason they seem intuitive is because we’re used to them. What would a total novice see?
New. A sheet of paper with a fold in it. How is that “create new document”? Why wouldn’t a new user just as easily think that it means:
- Blank out my document.
- Mark this page to return to later.
- Print a document (as in “give me a physical piece of paper”).
Open: An opened folder. But aren’t we supposed to be opening a document, not a folder?
Save: A floppy. What’s a floppy? Some users today have never seen a floppy, but even if they did, users almost never save a file to it. And can’t a floppy just as easily be used to retrieve a file as save one? So it could mean:
- Retrieve file.
- Show contents of media/floppy.
- Eject removable media/floppy (”give me the floppy”).
- Export/Save As to removable media/floppy.
Print: A printer. What about the printer? Set its attributes? Check its queue?
Cut: Scissors. Okay, scissors mean cutting, but cutting what? Connection to the internet? Link to another document? Assuming users know it means “cut out selected text,” then what? Cut out and discard (i.e., delete selection) seems like a natural assumption.
Copy: Two pages. But aren’t you usually copying a small block of content rather than an entire page? Why shouldn’t a user think this means:
- Duplicate page.
- Insert page.
- Reorder pages.
- Go to first page.
- Collate (when printing multiple copies).
Paste: Paper scrap by a clipboard. But couldn’t that just as easily be a scrap going on the clipboard? What’s a “clipboard” anyway? Users typically haven’t seen it since the early Macs. How many users today are aware of that metaphor? Who would guess that a clipboard is a place to get scraps of paper for pasting? That’s not what I do on my physical desktop. Why couldn’t this mean:
- Take notes/comments.
- Combine documents (clip together).
- Complete form (for something).
- Discard document (release from clipboard).
When it comes to labeling actions, words are vastly better than pictures. That’s why toolbars have tooltips. Yes, users can use tooltips to learn what the icons mean, and that’s okay for the user that occasionally needs a reminder for one or two items. It’s absolutely unacceptable for a user learning the app from scratch to have to “scrub” the toolbar hoping to find a command that may not even be there. It’s mystery meat navigation institutionalized into our desktop apps. Compare that exercise to what pulldown menu offers, where one click reveals a whole list of commands with text labels the user can rapidly scan for the command they’re looking for, vastly better than hovering over each command one at a time.
Commands need static text labels, not pictures. That’s why Internet Explorer by default shows text labels on their toolbar. MS Outlook now labels the key items on its toolbar because before, no matter how MS designers tried to modify the icons, users just couldn’t figure out what those toolbar items did. Such experience has lead MS to include text labels on many of their items on the new Ribbon, but, tragically, not all items. Eric Schaffer reports (on 8/9/2004) that on average users know only 6 Word toolbar items –after regularly using Word for 2 years. Users may be using the toolbar instead of the menu, but, thanks to the icon labels, they use only a few out of all the toolbar items presented.
My guess is that toolbars make it so users only know a few commands in the entire app.
Cloaked Control Classes
Check out the following toolbar items taken from MS Word:
Document Map
Allign Center
Text Color
Format Painter
What do the above toolbar command buttons all have in common?
Answer: none of them are command buttons.
When it comes to controls, great pains have been made to clearly distinguish among key types of controls so users know what to expect and how to interact. Command buttons, pulldown menus, check boxes, option buttons, combo boxes, and so forth each have a very distinct look, which is considered vitally important to usability. Standards purists (myself included) tear their hair out if they see a check box used when it should be an option button, or a combo box serving as a pulldown menu (commonly done on web sites). We insist that if a button or menu item opens a dialog then its label end with an elipsis. Yet somehow, these essential features of controls go out the window when it comes to toolbars. No matter what it is or how the user uses it, it all looks the same.
A toolbar item, such as Paste might be a command button have acts immediately. Or maybe it’s a command button that opens a dialog first, like Open. There’s no way to tell by looking at the icon. It might be a check box, like Document View or Bold, or Italic, toggling an attribute on or off. Or maybe it’s an option button, like Align Center, where only one value among many can be applied at once. Except that, just to confuse matters more, if Align Center is on, and you click it again, it goes off, with alignment reverting to the default of Left Align, like a check box, kinda, sorta (you probably never discovered that on your own, maybe because it is unlike everything else in GUIs).
The Bold and Alignment items tell you the attributes of the current text, which is pretty cool in principle. And experience with their ilk might lead you to look at Text Color and conclude it tells you the current color of your text. Bzzt. No, that’s not a check box or option button, but a combo box, kinda sorta. You select the color you want for your selected text from a dropdown (arrow for which I unfairly cropped off in the above image). The color you see in the icon is not the color that is but the color you get if you click it directly.
And the Format Painter? Why, bless me, its the original tool in the toolbar. Selecting it puts you in a mode where an action is applied by dragging the pointer over some target object. But users can tell that just by looking at the icon, right?
So even if users can tell what your icon is a picture of and can figure out what command that means, they’re still left guessing on how the toolbar item actually carries out the command. This all contributes to the uncertainty users feel. Uncertainty means fear. Fear is not a positive user experience. As a UI designer, unfortunately, there’s not much you can do about it unless you want to make your own custom-appearing toolbar controls which graphically distinguish their behavior like conventional controls.
Icon Overload
I skipped a step. Before your user looks at your icon, figures out what it is and what it means, and guesses how it works, the user has to find the toolbar item in the first place, which she or he won’t because there’s just too frigging many toolbar items. We have brightly colored toolbars, each with their multitude of cryptic icons, arrayed two or three or more rows high that obscure not only the menubar but each other. Where do users start to look for a command? There’s some sort of organization of toolbar items into toolbars, but, like the toolbar items themselves, the toolbars are unlabeled, making such organization a mystery. It took me years of regularly using Word’s Document Map from the menu before I realized it’s on the toolbar. Users are supposed to go from the menu to the toolbar with regular use of a feature. Word even cleverly includes the toolbar icon on the menu item to facilitate this transfer. I don’t think it works, because even when you know the icon to look for, it’s too hard to find in the vast haystack of today’s toolbars. The careful balance of breadth versus depth that menu designers agonize over is forgotten with toolbars. Here’s what we typically show the user (click for full size):
And this is what they see (click for full size):
No wonder new users can’t find features in apps. I mean, it’s just overwhelming. They have to put blinders on and filter out almost everything just to be able to focus on the actual task at hand, like writing something.
Once apon a time toolbars were supposed to include just the more common commands that users frequently used. I’ve no idea what criteria is used today to decide what needs to be on a toolbar. Maybe it’s just a mentality of, “Oh, what harm could just one more toolbar item have? Someone might need it.” For example, how can you not like Word’s Undo toolbar item with all it’s power and efficiency all in one little icon? It quickly supports a single Undo but also includes a dropdown menu to execute multiple Undos at once. Not even the Undo menu item can do that. By itself it’s easy to argue how handy and downright cool a given toolbar item is. But what we have here is Tragedy of the Commons. Each item by itself is beneficial, but put them all together and in aggregate you start getting problems.
How many of those toolbar items do users really use frequently? Why would a user ever want a toolbar item to display a toolbar (e.g., the Web and Drawing toolbar items in Word). Why on Earth is something like Insert Spreadsheet a toolbar item? Why do I get the feeling that was put in by Marketing? Even Cut, Copy, Paste –are they really used that frequently? Aren’t the accelerators Control-X, C, V (not to mention the context menu) good enough for shortcuts?
Leaner and Meaner Toolbars
If we’re going to use toolbars at all, the solution is clear. We need to get the toolbar back to where it belongs, as a shortcut for experts for the most commonly used commands. Right now, things are backwards, with novices invoking commands from the toolbar, for which it’s completely unsuited due to its lack of text labels, while only experts use the menubar like it were an “advanced” button in a dialog box. The pulldown menu should resume its role as the first place to learn about commands, from which users then graduate to the toolbar or other expert shortcuts.
The way to do this is to put our apps on a toolbar diet. Like tabs and other idioms before, the toolbar is one of those great ideas that solved a problem but now are way over used. Fewer toolbar items means fewer opportunities for confusion due to the bad terminology and lack of visual difference. The truth is a lot of toolbar items can go away without impacting the application’s function or usability. In fact it can improve it by reducing clutter, providing a consistent means of interacting with the application, and returning real estate to the document.
It’s not enough for a command to be frequently used to be allowed on the toolbar. The new rule should be, “It only goes on the toolbar if it’s frequently used and there’s no better way to allow easy expert access.” Here’s a set of rules to apply to achieve this:
No toolbar items for commands that are really rarely used. It’s always tempting to say, “Hey, let’s give this feature a toolbar item. What can it hurt?” But for every toolbar item you add, you make it harder for the user to find every other toolbar item (not to mention the menubar). So it better be there for a good reason. Anything that isn’t used by most users every day they use the application has no business on the toolbar.
No toolbar items for commands that can be effected with a menu accelerator. Given that any commonly-used menu item should have an accelerator, this comes down to eliminating all toolbar items that are redundant with a menu item. New, Open, Cut, Copy, Paste, Find, the whole lot. There’s really no reason to have two shortcuts for the same command, and accelerators are generally superior to toolbar items (see Lane, D. M., Napier, H. A., Peres, S. C., & Sándor, A. (2005). Hidden costs of graphical user interfaces: Failure to make the transition from menus and icon toolbars to keyboard shortcuts. International Journal of Human-Computer Interaction, 18(2), 133-144). As an expert shortcut to a menu item, the accelerator is faster than the toolbar item: the toolbar item requires the user to switch a hand to the mouse if the user is on the keyboard, but accelerators don’t require the user to switch a hand to the keyboard because the hand that isn’t mousing can already be hovering over the keyboard. A toolbar item then requires the pointer to be slewed over half the screen on average to a small target before clicking. Accelerators can be executed immediately. Click-click.
And I wouldn’t bet that memorizing accelerators (like Control-F for Find) is harder than memorizing those unintelligible icons of toolbar items. Choose your accelerators well, display them in the menu items, and it may be even easier. Users know where the keys are, but can they find your icon? Besides, expert actions are for experts –a memory burden is not the primary consideration.
Some designers will cry, “Wait, redundancy is good. Sometimes users may be faster with a toolbar item, sometimes with accelerators.” Maybe, but I doubt it. Redundancy isn’t harmless. Give the user multiple ways to do things and not only do they have to decide what to do, but how to do it. That extra decision adds workload and delay each time a command is executed often eliminating in aggregate the time savings from having different ways of doing things for different situations. Also, I’ve seen that new users are confused by being told multiple ways of doing things. It slows learning, reinforcing multiple behaviors rather than focusing rehearsal on one behavior: They’re like, “Wait, I thought last time you told me to –oh never mind, I’ll try to learn this way.”
No toolbar items that open a dialog or otherwise do not perform an immediate action on the document. Actually, if it opens a dialog (1) it is or should be a rare command, and (2) it’s probably redundant with a menu item, so this is usually covered by the above. But in any case, by the time the user goes through the dialog or whatever to execute the command, the proportion of time saved by using a toolbar item is miniscule. Yes, the absolute time saved is just as much for an equally common command that has no dialog as an intermediary, but if you really want excuses to excise toolbar items, then consider ditching those that also have little experienced value to the user. This rule applies, by the way, to any toolbar item that just adds another toolbar.
When possible, use direct manipulation (DM) techniques to execute the command rather than using a toolbar item. Do you really need a toolbar item to set the size of your font in your application? What if selecting the object put handles around it, allowing the user to directly drag the font to the desired size? Why have indenting and alignment toolbar items when you already have a perfectly serviceable ruler that can do that? What if selection handles appeared on your diagram that allowed the user to choose all or some of the diagram for some action, eliminating a slew of Select This and Select That toolbar items? Such DM techniques may not be appropriate for some applications (handles add clutter too), but I get the feeling that designers today rarely even consider DM. Like accelerators, DM is an expert short cut that is often superior to a toolbar item for experts because it eliminates slewing the mouse across half the screen and back. Eyes and pointer remained focused on the work at hand.
Convert appropriate toolbars to a view or properties pane for reviewing and modifying an object’s attributes. This provides the fast functionality and visual status information for toolbar items like Bold and Alignment, but also the self-documentation of a dialog box. All toolbar items become text-labeled and distinguishable controls like check boxes and combo boxes. More on this technique in a later post.
Consider implementing expert activation. Some toolbar items just execute whatever is the current parameters for a command otherwise executed through a dialog (e.g., the Print and New toolbar items in Word). A bunch of toolbar items could be eliminated if we widely used the convention that control-clicking a menu item (that normally opens a dialog) would execute the command with current parameters as set in the dialog. It’s not quite as fast as toolbar item, and it’s has even less self-documentation than a toolbar item, but maybe many of the relatively less-commonly used toolbar items could be replaced with this truly expert shortcut.
Apply all the above, and it leaves only two things on your toolbar:
- A toolbar item that really is a tool –that is something like a paintbrush or Draw Rectangle that changes the way the mouse pointer works.
- A toolbar item for a commonly used command that is nonetheless buried in a Dialog box. For example, something like Find Next and Find Previous, which a user is likely to use often and repeatedly.
That doesn’t leave much.
Putting My Money
I’ve used MS Word for a lot of examples of what’s wrong with toolbars, but it happens that Word and the rest of the Office suite have an excellent toolbar customization feature, something you should consider for your app if, like with Word, it has wide differences among users on what are the most common commands they use. Using Word’s customization abilities this Spring I applied the above rules (as applicable and possible) to my installation of Word, including on my toolbars only items that I used frequently and couldn’t access otherwise (at least by any way I knew how). Here’s how it ended up (click for full size):
For me, it’s a great improvement. Subjectively it feels much easier to find toolbar items, and overall its less distracting. I’ve more space to display my document, and I find myself using accelerators more, interrupting my typing flow less. I was concerned about not having Bold or Italic to show the current attributes of my text, but so far that’s not a problem, maybe because I don’t use obscure fonts for which recognizing bold and italic on sight can be difficult. I’ve since learned accelerators for superscript and subscript, so the toolbar items for them may go shortly. On the other hand I’m considering bringing back the Indent and Outdent toolbar items. As implemented, dragging the Ruler controls can be a pain, especially doing it consistently for multiple lines at different times. Also, I have to slew 90% of the way to the toolbar to access the ruler, so drag and drop isn’t making it any easier.
Try it yourself. It might make you reappraise all the toolbar items you thought you needed in your own app designs.
Icons for Discrimination, not Recognition
With your toolbars reduced to just the things experts really need, the problem of interpretable toolbar items becomes much less an issue. That being the case, I wouldn’t worry about doing the impossible and making your toolbar icons interpretable. Your priorities are now to make them discriminable (from each other), memorable (so once users learn them, they remember), and standard. Yes, maybe you could improve the standard icons, especially obsolete ones like Save and its icon of a floppy, but don’t. Experts are used to it, and experts are what toolbars are for. Just as a red octogon means stop, the image of a floppy is established to mean Save, even if it is pretty much an aribitrary symbol, not unlike a red octogon. By all means, work hard to make your icons mnemonic and avoid outright misleading icons, and certainly conduct usability tests to confirm they are discriminable and memorable. But don’t even waste time testing icons on users who’ve never seen them before to see if they can guess what function they invoke.
Alternatively, if you really do want your novice users using the toolbar items, include a text label with each item. If your app has been put through its toolbar diet, then you should have more room for text. Or, go radical and use text instead of icons. Some say icons save space over text labels, but I’m not so sure. A lot of these labels are pretty short. Count the number of pixels used by a label like “Print.” I get 231. A 16×16 pixel icon is 256. Hmm. Some labels will be longer, but I expect it makes little difference in space in aggregate. As for really long command names, I see no reason why the toolbar can’t use abbreviations. You can bet that users will have a better chance figuring out a text abbreviation like “Doc Map” than they will guess what does. And remember, the toolbar is for experts after all; there’s the pulldown menu for the full name, and you can still use tooltips to show the full name on the toolbar too.
Summary Checklist
Problem: Countless cryptic toolbar items clutter your windows causing confusion.
Reasons:
- Confusing terminology in documentation.
- Reliance on tiny pictures to convey actions.
- Behavior not predictable from appearance.
- Just plain too many.
Potential Solutions:
- Adopt a new standard terminology that more meanfully describes toolbars and their items.
- Adopt new standard appearances for different toolbar item types that indicate their behavior.
- Limit the toolbar to true tools or controls that activate frequently needed commands otherwise only available through a dialog.
- Design and test icons for discriminability and memorability.
- Use text labels in addition to or instead of icons if the toolbar is expected to be used by novice users.