Making Menus and Toolbars More Usable by Treating Items as Attributes.
This is the third in a series of what’s wrong with pulldown menus and toolbars.
We want everyone to be happy. We designers recognize that users come in all sorts of shapes and sizes, have diverse skills, knowledge, and experience, and we endeavor to make a user interface that works well for them all. Take the menubar and toolbar combination, an effort to make the UI work with everyone no matter where they are along the novice-to-expert dimension. It’s a compelling idea: menubar for novices, toolbar for experts. All commands are in the menubar (somewhere), where novices can find them by following the information scent of relatively clear text labels. For example, if the novice wants to set some text to appear bold in a word processor, she or he will naturally scan across the menubar, eyes landing on Format (bold is a form of formatting), with a click, eyes next see Font (bold is the formatting of a font), another click and a dialog box opens, and there in a Font Style list box is Bold. Click, click, and one happy empowered novice.
But those four clicks get awfully tedious when the user is an expert, burdened with setting text to bold all the time. So we provide the toolbar, serving as shortcuts to selected high-frequency commands found in the menus and dialog boxes. Bearing cryptic symbols and lacking grouping labels (like Edit, View, and Format), no one would expect a novice to use the toolbar, but the expert has learned the toolbar symbols (that’s what makes them an expert) and is inclined to use the toolbar to save time and effort. Bold text? Click. You got ya bold text with about a quarter of the effort.
Well, that’s the way it’s supposed to work, but there are several problems.
Problem 1: Questionable Menu Labels
As I’ve discussed earlier, the information scent provided by conventional menu labels is not very strong for novice users. Format is actually a pretty good menu label, but in looking for Bold, the user could easily be distracted by Edit (as in, “Edit the boldness of my text”) and View (“I want to view my text as bold”), and Tools (“I need a boldifier tool”). From what I’ve seen, the traditional menu labels largely fail in their pedagogic function. They don’t really serve novices.
Problem 2: Transition to Expert
Logically, all users start as a novices. So how do they get to this expert state where they know and use the toolbar? You have your Cooperesque perpetual intermediate users slogging through four clicks to set text to bold. How does it enter their respective heads that, “Hey, wait, I can just click this big fat B on the toolbar”? First of all, they have to understand that the toolbar is redundant with the menubar –that just because something is done on the menu doesn’t mean it can’t be done on the toolbar. Why would they think that? Who tells them?
Even if they knew that, how do they know a particular command is on a toolbar and therefore worth looking for? And what do they look for? Pre-2007 Microsoft Office cleverly provided this information in the menu itself, showing the toolbar icon in the menu caption. But not all things on the toolbar are in the menus themselves. Some, like Bold are actually in dialog boxes, where no icon is provided (although I don’t see a reason it couldn’t be). Indeed, if you follow my advice and limit toolbar items to commands executed through dialogs, the user never has those icons on the menu item captions to guide them.
But even if the user has seen the icon somewhere, or the icons are so supremely designed their functions are fairly easy to guess, now the user has to go looking for the icon, searching the cluttered unlabeled toolbar(s) for a dinky little picture (this isn’t a problem with accelerators, which are also displayed in the menu item caption –users know where the keys are since they’re already using them all the time). The icon might be on one of several possible toolbars, maybe one that’s not even visible at the moment, significantly complicating the search.
Does an icon in the menu item caption necessarily mean the command is on a toolbar? In the case of MS Word, I’m not so sure; I’ve yet to find the toolbar item for Save as Web Page, for example. After seeing the icon on the menu, at what point do they just give up looking for it on the toolbars? Furthermore, just because the same icon appears in both the pulldown menu and the toolbar doesn’t mean they are quite the same command. The New, Open, and Print menu items in MS Word all have the same icons as on the toolbar. However, only Open is identical in both places, opening a dialog box to select a file. New and Print menu items open a dialog box for the user to choose command parameters, while New and Print toolbar items execute their respective commands with default parameters. That can be a surprise.
So, learning a toolbar item means:
- Deciding the associated command might be on the toolbar.
- Searching (perhaps serially) for the command within and across toolbars.
- Comparing each icon with some idea of what it should look like, which may or may not be provided by a menu item caption.
- Verifying the effect of the toolbar item by trying it out or reading the tooltip.
It’s a wonder any novice ever graduates from using the menu to the toolbar.
Problem 3: Novice Use of Toolbars
And that’s because novices usually don’t graduate to the toolbar. Oh, sure, toolbars get lots of use, but I think the vast majority of that use is by users that have always used them. They didn’t start out with the menubar and move to the toolbar. They’ve used selected toolbar items like Bold since they were novices. Why? Because, the local “computer wiz” two cubicles down told them too. That’s how people learn software. The problem with that is the toolbar is being used by users it was never designed for: novices. In a user’s first exposure to an app, they immediately find themselves in the deep end, trying to read mystic runes apparently randomly distributed across the top of their window. The whole idea behind a menu-driven user interface is that users can rely more on recognition, and less on recall, but this is undermined by making them learn the hieroglyphics of clipboards, scissors, magnifying glasses, and other images that defy identification.
Problem 4: Clutter Through Redundancy
It seems everyone these days is acknowledging that apps have gotten too complex. MS Word, for example has approximately 3000 commands. It’s an astonishing usability challenge to organize that number of commands into any kind of menu system that provides fast and easy-to-see access. The potential to overwhelm the user with clutter has to be fought on all fronts. And yet, by having a menubar and toolbars, we choose to add to the clutter by presenting the same command in two different places.
Conventional usability wisdom says redundancy is good. Provide several ways to do the same command so the user can choose the best way. There is an element of truth to that point of view. Having multiple ways to do the same command makes sense if the ways are truly different, for example, each way using a distinct delivery style like drag and drop, a menu item, and an accelerator. However, in the case of the menubar and toolbar, the redundancy is in the same style –both are essentially menus –so such redundancy does not offer the user that much flexibility.
There is insidious cost to any redundancy. More ways to do a command means more imagery in the window, adding to the clutter, making it harder to find all commands. Also, if the users know two ways to do the command, now they have to decide which way to do the command, an added element of their workload that can negate the savings the optimal way to do the command has over its alternative.
If the users generally do not know the multiple ways to do a command, having multiple ways undermines the user’s capacity to learn new commands. Lacking sufficient exemplars of commands with multiple means of application, the users don’t form a good picture of how commands are organized in GUI. Thus, learning users cannot be expected to have any effective rules for where commands can be found. Oh, sure, you can tell them that if it’s a common command it’s on the toolbar, but how is a novice users supposed to guess what the designer has decided is a “common” command? If a command could be anywhere, where do users look for a new command? Rather than going straight to the menu (and maybe later move from there to the toolbar), such users think they have to look everywhere, a hopeless task when menu items and toolbar items number in the hundreds. The command may not even exist, or may not be recognized when it’s seen. Better to ask the guy two cubicles down again.
To many users, some commands are done through the menu and some through the toolbar because they just are. Maybe even some others are done via accelerators or context menus or drag and drop. There’s no apparent pattern to how commands “should” be done, but rather it just has to be memorized by rote. If you regularly teach novices new commands, you’ve probably faced irritation if you say something like, “you can also do it by—.” To novices, it’s hard enough trying to remember to click on “View” (whatever that’s supposed to mean), without also trying to learn a silly little picture of a magnify glass buried deep among a bunch of other symbols.
It’s fallacy that we can solve the problem of complexity with more complexity. The menu is too complex (in the sense of number of options and number of clicks), so we add the toolbar with some of same commands to make accessing common commands simpler. Now the toolbars are too complex (too many items with perplexing symbols), so we try adding icons for yet more of the same commands in the window work area.
Users still can’t find the command, so we try a task pane on the left side with a list of still more of the same commands.
Or how about a command button or three?
I know, let’s use links.
Where will it end? Yes, redundancy can be good, but how much really helps complexity and how much makes it worse? I count 10 ways to open a Word document. Surely we can have couple less for the sake of simplicity.
Usability problems are rarely solved by the user. For example, Jef Raskin warns in The Humane Interface that adding Options or Preferences to cope with individual differences can produce more problems than it solves. When confronted with two alternative UIs, each with apparent pros and cons, designers too often choose to make the users pick the one they want under Options or Preferences (as if the user has the expertise to make the right choice). That is clearly bad design. However, that is essentially what we’re doing with this menubar-for-novices-toolbar-for-experts design. Because we couldn’t figure out a solution to the novice-vs.-expert problem, we expect our users to solve it for us.
Novices and Experts Together Again
The idea of a menubar for novices and a toolbar for experts has in practice failed us. Instead of two menu-driven ways to select the same commands, one for novices and one for experts, our users would be better served if we had one menu-driven way that serves novices and experts equally. Each command should be selectable in a manner that is easy to find and recognize by the user, but as fast as possible to select for the expert. This goal to have “one stop shopping” for commands was a major driver behind Office 2007’s new “ribbon.” It may not be technically feasible or even desirable to employ a ribbon in your app. However, assuming you’re stuck with the traditional menubar and toolbar, you may still be able to get one-stop shopping for at least some of your commands. This is because there’s a good chance that some of your commands have no good reason to be on the menubar and toolbar at all. And that’s because they’re really not commands.
Consider the toolbars for MS Word 1.0, one of the earliest examples of toolbars that provided shortcuts for items otherwise accessed through the menubar items. One thing that contributed to the success of early toolbars like this is that not only did they provide fast access to commands otherwise deep in dialog boxes, but also it showed the state of the selected content or the insertion point. At a glance, Word 1.0 users could see the characteristics of what they are about to type: alignment, spacing, style, font, size, boldness, italic-ness, etc. These toolbar controls do not so much represent commands as attributes of the current text.
Pulldown menus and modal dialog boxes cannot provide the continuous display of attribute values of the content the user is creating. Modal dialog boxes, such as Word’s Format Dialog cannot be displayed while the user is typing or editing the document. In pulldown menus, attributes are represented with “settings” menu items, where a checkbox or other symbol indicates if a particular value is set. The attribute values set in such menus can only be seen by clicking the menu, which disappears once the user returns to the content.
By being always visible, toolbars such as seen in Word 1.0 support an important function that menus and modal dialogs don’t. Both experts and novices would benefit from the feedback provided by toolbars’ ability to continuously display the attribute values of the user’s content. There’s nothing about being experts that makes them exclusively interested in this. However, toolbars are designed for experts. The controls and groups of controls lack labels, making it harder for a novice to find or understand a particular attribute. Controls all appear much alike, generally as a small command button, but may behave markedly differently, potentially as command buttons, option buttons, checkboxes, pulldown menus, or dropdown lists. This may lead to confusion for novices when the controls do not perform as expected. To make the reading of the attribute values usable to the novice, a toolbar will not do.
The Detail Pane
Fortunately, there is an alterative to the toolbar for displaying the controls for showing and setting content attributes. It’s the detail pane or “subform” from the tradition of database user interfaces. A detail pane is a region of the window that provides the details of the current selection or position in a master region. A common example of a detail pane can be found in many email clients: a master pane lists the Inbox, Sent, and other folders, while its detail pane list the letters in the current folder; often the list of letters is itself a master pane for detail pane showing the contents of the letter. The same can be used to show the attributes of any object, as can be seen for example in the Properties pane of MS Visual Studio. In the case of a word processor, for instance, the detail pane may show the font, paragraph, and other text attributes for the current selection or insertion point.
While a toolbar is usually put at the top of the window, a detail pane is usually located to the side of below of its master pane to establish its relation to the master pane, but that is a minor difference from a toolbar. More significantly, unlike a toolbar, a detail pane has full labels for the attributes and the user can change the attribute values using conventional form controls such as checkboxes, text boxes, and drop-down lists. Other space-consuming controls, such list boxes and two-dimensional graphics can also be included if they are justified. Being easy to read and understand, the detail pane becomes a toolbar that is friendly to the novice.
Unlike a dialog box, the detail pane is modeless, never preventing interaction with the master pane. The values shown for the attributes in the detail pane update instantly as the user changes the selection or the insertion point in the master pane. Likewise, changes to the attributes performed in the detail pane are applied instantly and automatically to the master pane –there is no Apply button. Unlike a dialog box, an attribute can be changed with as little as a single click. Being as fast to use as a toolbar as well as continuously visible like a toolbar, the detail pane is superior to the equivalent menu item and dialog box combination for commonly needed attribute changes.
The main drawback of a detail pane over a toolbar is that, by having labels and full controls, it tends to be more space intensive, consuming more window real estate. However, for many situations, this is probably a good trade. If the attributes need to be seen and changed often, then they deserve to be fully represented to expert and novice alike, and are thus better off in a detail pane. If the attributes do not need to be seen or changed often, then they are not on the toolbar anyway, but in an out of the way dialog box –there’s no redundancy to eliminate. Furthermore, the space-intensiveness of a detail pane can be mitigated by making the pane closable, so the user can have the full window when it is necessary. There’s no reason this can’t be done with a single click using something like a disclosure triangle or a Java Swing “tap,” which makes hiding or showing a detail pane about three times faster than hiding or showing a toolbar via a View – Toolbars menu. A detail pane’s size can also be minimized by using tabs or “More” buttons, making the most important attributes easily accessible, but still providing a path to less frequently needed attributes.
Unlike a task pane, a detail pane should not be yet another means to execute the same commands that may be accessed through the menubar and toolbar. Serving novice and expert alike, a detail pane can replace both the corresponding toolbar items and menu items and dialog boxes. A word processor with a detail pane has no need for a Paragraph and Font menu items and dialog boxes as well as their redundant toolbar controls. They can all be removed, eliminating some of the control redundancy in the app and the confusion it can produce.
With items in the detail pane, we eliminate the problem of transitioning users from a novice form of interaction to an expert form; now there isn’t any transition. Rather than novices using the menubar and experts using the toolbar, all users use the detail pane. Attributes for whatever the user is working on are consistently found in the detail pane, so when a user wants to change something, they only have one place to look.
Using a Detail Pane
To simplify your menus and toolbars and reduce redundancy, search through your menus and toolbars for candidates for a detail pane. Candidates are things that are really attributes rather than true commands, or at least can be represented as attributes. That is, the only “command” the toolbar or menu item executes is to simply set the attribute values of something. This is distinct from commands like Save, Print, and Find that actually perform some sort of process on the content or data objects handled by the app. Candidates for a detail pane include commands that set a data object’s name, dimensions, position, shape, color, format, style, orientation, appearance, flavor, age, hairiness, extroversion, inclination to the Dark Side, etc.
Candidates on the toolbar are often distinguishable by fact that they are not command buttons, acting instead like drop-down lists, toggling buttons, sliders, checkboxes, option buttons, and other controls used to set attributes. Candidates in the menus are any setting menu item –any thing that can have a checkmark. Candidates are also menu items whose caption includes the verb “Set” or “Change” or “View” and the like –weak verbs that imply little action. Or the caption may have no verb at all (e.g., Word Count). Likewise, dialog boxes whose execution button is “OK” or “Done” or “Close” rather than an active verb can probably be moved wholesale to a detail pane. Within dialog boxes, candidates can be found by asking the question, “Does it make sense for change to this to be applied instantly, without the need for the user to click a command button?” If so, it’s probably an attribute and can be put in a detail pane. If not, it’s probably a parameter to a true command.
In database, line-of-business, and process control software, items can often be moved off the menubar and toolbar by representing them as objects. For example, the original design for a data collection or process monitoring software (e.g., for video surveillance) may include menu and toolbar items to connect and control the sensors (e.g., cameras), and to record their output. As an alternative, the sensors could be represented as objects in a pane or a window, and controlled by sliders, spinners, dropdown lists, and other attribute-type controls. Checkboxes or toggling command buttons may be used to start and stop processes such as recording data. Representing the sensors as objects with editable attributes provides better visibility to the user of the state of the sensors while simplifying menubar and toolbar and reducing their redundancy.
In document-type applications like word processors, drawing programs, and spreadsheets, you may find your entire Format menu can be eliminated in favor of a detail pane.
Another menu that can probably be eliminated if not greatly truncated is the View menu. Its menu items have all the traits of candidates for a detail pane: the presence of settings menu items, weak or no verbs in the captions, dialogs with execution buttons labeled “OK.” However, unlike Format menu items, View menu items are not attributes of the content or data objects –they do not indicate the characteristics of the current selection or insertion point. Thus, they do not belong in a conventional detail pane.
Instead, View menu items are attributes of the view of the content –the characteristics of how the content is displayed at the moment. View menu items and toolbar items can be replaced with conventional attribute-type controls, but it needs to be made clear to the user that they represent the view not the content. One approach that can work is to place them in the border of the pane they apply too. I would recommend the top border to maximize visibility (the Office 2007 designers found that something like this is hard to find at the bottom of the window).
In a word processor, for example they can be placed at the top of the window, where toolbars are found now. It’s in the place of a toolbar, and acts like a toolbar, but it’s different in the two features that distinguish a detail pane from a toolbar. Firstly, it is fully labeled like the controls in a detail pane, so it is usable by novices as well as experts. Secondly, it is not redundant with anything in the menubar. It doesn’t need to be since it’s usable by novices.
In a hypothetical word processor, converting various menu items to attributes in detail panes would look something like this:
The Format and View menus are eliminated, simplifying the menubar. Using detail panes for attributes plus applying my previous recommendations for toolbar usage, there remain only two toolbar items: New Document with Default Template, and Print to Default Printer. All other toolbar items are now fully labeled attributes across the top of the document or in a detail pane below. A Swing-style “tap” allows one click hiding of the space-intensive Format pane, and a More command button expands the format pane to include more esoteric attributes (e.g., justified alignment, borders and shading).
So consider detail panes to reduce the problems of the menubar and toolbar. Doing so reduces unnecessary redundancy while providing equally for experts and novices. Furthermore, by removing items from the menubar and toolbar that are not true commands, the menubar and toolbar are simpler, so whatever problems they continue to have will have less of an impact.
Problem The menubar and toolbar combination fails in its attempt to provide a satisfactory UI for novices and experts. Instead, it introduces harmful redundancy, poor visibility for novices, and an awkward transition from novice to expert.
Potential Solution: Remove from both the menus and the toolbars any commands that can be represented as attributes and place them in detail panes.
- Format and other attributes of data objects or content can be placed in a detail pane below the master pane.
- View menu and toolbar items can be placed at the top of the associated pane.
- All items are fully labeled.
- Controls can be used to mitigate the increase consumption in real estate, allow the user to hide and show the detail pane or parts thereof.
Next Time in the Menubar-Toolbar Series
In the penultimate article in the menu and toolbar series, we’ll answer two questions:
- Is Microsoft Office’s new ribbon the answer to the main problems with the traditional menubar and toolbar?
- Why isn’t it?