The first in a series about menus and toolbars.
How Did Pulldown Menus Get So Confusing?
Aren’t menus friendly? How nice to have a well-categorized list of all the actions of an application. No need for a reference manual of commands, the user can just follow the “information scent” through the hierarchy to the right menu item. Can the application do x? Look in the menu. Hey, did you know it can do y? Saw it in the menu. With standard menus like File, Edit, and View, a user can predict from experience with other apps where an action will reside, even an action unique to the current application.
If you’re like me, with a fair amount of experience with personal computers, you’ve got friends, colleagues, and relatives who come to you asking how to do a particular action on a particular application. You probably have had the experience of sitting down at an app you’ve never used before, and you figure it out faster than the person who has actually been using it. That’s not too surprising if the user is relatively new to computers. It takes time to develop the concepts of what’s represented by each standard menu. But I believe I’m witnessing users that don’t seem to ever develop such concepts. Years go by and they don’t know where to start to figure out how to do something new in an app. They can breeze through more complex and less familiar menus on web sites, but can’t guess that to convert an image to a GIF, look first under File. Why?
Foggy Names
File, Edit, View –what do these really mean anyway? They’ve been sitting at the tops of windows for so long, it’s easy to forget that as words alone, they’re really not that descriptive. View, uh, so if I want to view a new document, go there right? Or if I want to view the Clipboard or Options? I want a view showing the changes I’ve made to my document, but after I view the other document I already have open. To the user, the File, Edit, and View labels are overly vague, offering little information scent, particularly Edit and View. Nearly any action you can think of is connected to editing (changing something) or viewing (displaying something), or both.
The problem is that one short word is just not enough to really inclusively and distinctly describe all the menu items within these menus. For Edit, for example, what we really want to say is “Actions that change the content you’re working on (as opposed to the form of the content, or, say, changing your toolbars),” but that’s not going to fit well on a pulldown menu. Even if you could put multi-word labels on the menubar without confusing users on the boundaries of each menu, I wouldn’t necessarily advocate it.
One solution is to somewhere provide some sort of more detailed description of the menu, such as when the user holds the mouse pointer over the menu label. This is done already for individual menu items in many applications (e.g., Windows Explorer). Unfortunately, usually the description is shown in the window’s status bar, about as far from the user’s attention point as possible (how many of you even noticed that Windows Explorer has this feature?). A better approach would be to use tool tips so the description is next to the menu label the user is pointing to.
Might be worth trying, but on a Windows platform something close to this functionality already exists: if the user clicks on any menu label, the menu items drop down and then the user can then simply slew the pointer horizontally over the menubar and see the menu items for every other menu. Seeing example menu items is often an excellant way to describe menus, but this functionality doesn’t seem to have prevented the problem of understanding what each menu represents. Maybe users just need to be told to use this trick when searching for an action.
In any case, we show only “Edit” on the menu and leave it implied what the user can edit. We assume the user will assume that unless otherwise specified, the content in the window is the default object for any action (same can be said for View). We rely on users grokking the connotations of these menu labels just from repeatedly seeing and using the items in the menu. There’s not much that can be done to improve these menu labels. Firstly, these are standard menu labels, so there’s a consistency cost for being different than most other apps that your more experienced users are already used to. Secondly, you probably can’t come up with better single-word labels.
What you can do is choose good menu names for any remaining menus in your app, avoiding those that have essentially no distinguishing meaning, at least from the perspective of the user. The Tools menu, as seen in many applications, is a common example of a meaningless menu label, and, thankfully, it appears that at least Microsoft Office is discarding this label. I mean, isn’t pretty much every menu item some sort of tool for accomplishing something? Here’s more for the blacklist of menu names, all which I’ve seen in production software:
- Actions (or Action).
- Advanced (how does a user know what counts as advanced?).
- Commands.
- Functions.
- Menu (yes, a menu call Menu).
- Miscellaneous.
- Options (not meaning preferences).
- Special (c’mon, every menu item is special!).
- Utilities.
Once I saw an app that had a Utilities and a Tools menu. Never understood what it meant.
Implementation Smog
The limitations of single-word menus is nothing new, yet it seems to me users these days are having an increasingly hard time finding things in menus. Something else must be happening now in combination with the limits of menu labels. Perhaps there are more cases of menu items being placed in inappropriate menus. Given the user comes to understand the specific meaning of the menu by seeing the menu items, it only takes one or two poorly placed menu items to throw the user off.
Misplaced menu items are typically the result of designers selecting a menu for a menu item based on the implementation of the features supported by the menu items, rather than considering how the user sees the feature. Chief among this is placing menu items for features in menus not by what they do but by how they do it. For example, in Windows XP Windows Explorer, Search is under View. Why? Looking at the other menu items in the View menu, we see View primarily controls how the content objects or window itself appears, as is the case for most other applications. The Search feature does nothing like that. In fact, objects found by Search are displayed in an entirely different window. However, the Search menu item in Windows Explorer makes the Search Explorer Bar appear, thus changing the current window’s “view.” Ack! How’s the user supposed to know that? How are they supposed to even know what an “Explorer Bar” is? (That’s the name of the cascade menu that Search is under, in case you haven’t found it yet.)
It’s all implementation details that may have been important to the designers, but the user doesn’t know and doesn’t care. They want to search for files, not display an Explorer Bar. The best place for Search in the existing menubar is in File. Alternatively, Windows Explorer needs a separate menu for specifying what files to show. Items on the Go To cascade menu in View could go there too. “Go” is not a bad label for such a menu (that’s what the equivalent menu in Outlook uses), but I’d want to test it against other possibilities like “Choose.”
Windows Explorer is not alone. Microsoft seems to have gotten it into its head that the way to provide quick access to controls for complex and transitory tasks is by the user showing and hiding toolbars through the View menu. MS Office in particular likes to hide features by putting them in View. If you want to draw lines or other shapes in Excel (e.g., to customize a chart), you don’t go to Insert, or Edit, or even the all-purpose Tools. You go to View – Toolbars. That’s where you access the Drawing tools. I’m not surprised that few people realize you can draw lines in Excel. Another case: I’ve mentioned before my fight with the fascist Word Mail Merge wizard. Silly me, I should have looked under View – Toolbars for mail merging, not Tools – Letters and Mailing. I’ve no idea how I eventually found the Mail Merge toolbar. I suspect I broke down and did the unconscionable act of using Help, but looking through the Help topics now, that would’ve required a remarkable filtering of information. It wouldn’t be so bad if the functionality within these toolbars was available elsewhere, just as the Format toolbar’s functionality can be reached by items in the Format menu, but they’re not. If the users don’t look under View, they might conclude the feature is not available.
It’s not just MS (it rarely is). If you want to change the thickness of a line in CorelDRAW, you don’t go to Effects, Edit, or even (what the heck?) Tools. It’s View – Roll-ups. Why? Because you change line thickness with the Pen Roll-up. Even if the users somehow know that a “roll-up” is a type of modeless dialog box, rather than a tasty fruit-filled pastry delight, how are they supposed to know that a roll-up is necessary to change line thickness? (Fortunately, the Pen Roll-up is also available from a fly-out menu on the drawing palette.)
Oh, wait, CorelDraw also has View – Dockers, yet another kind of modeless dialog box. It’s where you go if you want to insert a drawing of a wedge of cheese, but you would’ve guessed that (ironically, it doesn’t appear to let you insert a pair of pants). I’m guessing the Corel designers and developers were mighty proud of these newfangled roll-ups and dockers, and they are quite clever, but they’re no basis for organizing a menu.
I trust you don’t have a Wizards menu on any of your apps, do you?
Then there’s what to do about Options or Preferences. Hopefully, you’re persuaded not to put it in the Tools menu –you shouldn’t even have a Tools menu. Since the Preferences/Options are not the primary content of an app, you’ll of course keep it out of Edit, even if that is a standard on some platforms. Apple OS-X’s new application menu makes a lot of sense for holding the Preferences menu item. After all, Preferences are essentially the attributes of the application. That also might be a better place for menu items controlling the appearances of certain toolbars and status bars, since those are also a characteristic of the application, and we can thus leave View filled purely with menu items that control the appearance of the primary content.
Lacking an application menu, the best thing is to put Options in a menu of its own. If you have a lot of options, breakup that behemoth Options dialog box into several small ones, and make each accessed by a separate menu item in a Preferences menu. Multi-row tabs are nature’s way of telling you your dialog is too frigging complex. If you have only a few options, consider making each a separate toggling menu item under the Preferences menu. Who says Options have to be in a dialog? You can have your five most frequently changed preferences as menu items, and the rest in a dialog box. If you must put Options in one of the standard menus, I recommend File. File is the only menu that has a menu item that, like Options, acts on the entire application. It has Exit.
Can’t See the Forest…
Certainly the greater complexity of modern applications, entailing more menu items to search through, also makes it tougher for users to find things in the menus. But I don’t think anyone is seriously interested in making applications simpler. Besides, even more problematic is the competition from toolbars. Their bright colorful pictures, slightly less peripheral placement, and greater real estate coverage in the most commonly used applications tend to draw user attention away from the drab menubar. Take a look at MS Internet Explorer, for example. Somewhere in there are pulldown menus.
That’s unfortunate because, while toolbar icons scream for attention, they typically don’t have much to say, at least in any language the novice user can understand. But that’s okay, isn’t it? Toolbars are intended for experts who already know the menus, and are looking for a shortcut. Toolbar controls don’t need super-clear labels. The menubar is for novices, where concise but clear text labels help them choose their actions.
Except I don’t see novices using the menubar. They’re using the toolbars too. I think it has to do with how users learn computers, namely, informally from expert computer users. The novice user typically knows one or more people who “know computers,” whether it’s the geek three cubicles down or the cousin in Oregon. These people provide informal instruction, usually piecemeal, where they explain how to do one feature at a time with no overall curriculum or overview. So what do these experts tell the new users to do? The same thing they do themselves: to do x, click on this icon on the toolbar. In the remarkable event that the user actually uses Help to learn how to do an action, the result may likely be same. Help for MS Office often instructs users to use the toolbar for common actions such as save, zoom, and cut-and-paste. Formal training is not necessarily better. One user I talked to said the training provided by her work involved an instructor demonstrating the three different ways to do each action, while the students took notes. One of those ways was with the menubar, the rest weren’t. Pretty much a crap shot on what the user would end up doing.
The net effect is that novice users don’t use the menubar very much. They never gain enough experience to develop a sense of what each menu label means. If they know anything in the pulldown menus all, it’s just the menu items for few of the more esoteric and rarely needed “power-user” actions. Far from being helpful and friendly, the menubar is an unfamiliar wilderness on the edge of the known world, full of innumerable and possibly dangerous items, a place to be avoided if possible. Some users appear to have even developed “menubar blindness,” and mentally filtering out the menus as irrelevant, like they were banner ads on a web site or those REC TRK EXT OVR annunciators at on Word’s status bar.
What to do about it? You can put your application on a toolbar diet so the toolbar is less distracting. Probably half of you tool bar controls can be eliminated without hurting your expert users, but that’s a topic for a later post. Certainly we could encourage users to use the menubar more, in both our documentation and our one-on-one interactions. We could instruct users on the structure of the menu and how it can be used to find commands. But frankly, if we’re talking informal, piece-meal instruction, you’ll find that users rarely have the patience to that. They need to get their work done now, and don’t have time for fiddling with menus or listening to a design lecture. Try explaining why such-and-such a command is in this or that menu, and they probably won’t hear you or remember because what they really need to think about is what they need to do next to finish the job.
Clear-cut and Start Over
Maybe we need a more radical solution. Alan Cooper suggests in his book About Face 2.0 that File, Edit, and View may not be how users classify actions anyway. Do users necessarily care that an object must be selected to be acted on (and thus the menu item is probably in Edit)? Can they really appreciate (or care) if they are changing the underlying data or not, when they just want to “make it bigger”? Perhaps there are better ways to organize your menu items. Maybe we need new standards.
Maybe menu items can be organized by task, as Microsoft appears to be attempting with the Ribbon (e.g., with the Page Layout, Mailings, and Review tabs). You don’t have to build a Ribbon-like control to do this in your app. There’s no reason that pulldown menus can’t be task-based. Indeed, pulldown menus have an advantage over the Ribbon in this regard. Because the tab of the Ribbon persists between actions, the Ribbon has to include a junk drawer “Home” tab and the “minibar” so that the most commonly used actions are together easily available. With pulldown menus, there no need for a “home” menu –every menu item can go in the menu that is truly for one specific task. The “minibar” function can be fulfilled by a conventional toolbar, which would also include other frequently access controls, such as those in the Quick Access Toolbar, the status bar, and most of what’s in the Home tab. As a demonstration of what organizing by task can do for you, here’s what Word 2003 would look like with its conventional pulldown menus and toolbars organized like the Ribbon:
That to my eyeballs constitutes a substantially improved organization and simplification over the menubar and toolbars of Word 2003 (I’m not really satisfied with the menu names but they’re from Microsoft). You could have additional toolbars whose appearance is controlled through the appropriate menus (e.g., a Review toolbar displayed by a menu item in Review, not View), but there’s a better approach to achieve the same effect: tear-off menus.
However, it may be hard to define coherent tasks to slot each menu item, and we might end up right back with something quite close to the current menus. For example, the Ribbon remains recognizably organized as Filing, Formatting, Inserting, and Viewing tasks, either within or between tabs, essentially replicating much of Word 2003’s organization.
Maybe it is better for the users if the menu items are organized by the class of the object the actions act on. There might be an Application menu for actions on the entire application, File menu for actions on the file, Page menu for actions on the page, Text menu for actions on selected text, Insertion for actions at the current insertion point, and so on. To some extent, we see this already in the standard pulldown menus.
Huh? Didn’t I just say that standard menus are pretty much organized by task? Well, they’re organized by both task and class, sometimes for the same menu. File supports filing tasks and which are actions on the file. View includes displays modification tasks acting on the “view” of the content. Help provides help by displaying Help.
In any case, reorganizing by class may also not be a sufficiently radical change. It may make for long and redundant menus too. Think of how many menu items apply to the insertion point in a word processor, for example, and many of these will also be on the Text menu. But as a general approach, this might be worth exploring. Remember when you first discovered right-click context menus, and how cool that was? There is something attractive about organizing menu items by object class.
For many custom applications, such as those for database interface or process control, maybe the answer is to keep the menubar, but ditch the pulldown. Such applications often have relatively simple menus, or at least can have simple menus if you re-cast appropriate menu items as controls on the work area in the interior of the window. For a given window in these apps, often you need only about a dozen or so menu items, such as Open (or Query), Drill-down, Save, Print, Exit, Undo, Cut, Copy, Paste, Create, Delete, and Help. Grouping them appropriately, you can simply list these menu items across the menubar and easily keep it under an 800 pixel width, taking no more space than an ordinary menubar. You can thus eliminate the need for users to understand the File, Edit, and View labels by getting rid of them. Menu items would then be easier to see and faster to select, eliminating the need for a separate toolbar from the menubar. If you’re worried that users will confuse such a menu with pulldown menus, then give each menu item an icon along with the text label, as seen for certain Outlook or Internet Explorer toolbar items.
Plain language menu items in plain view. Now you have it all.
Summary Checklist
Problem: Users can’t discover features in the menubar.
Reasons:
- Vague menu names.
- Menus organized by implementation.
- Menubar overwhelmed by toolbars.
Potential Solutions:
- Tool tips for menu names.
- Avoid catch-all menu names.
- Place menu items by what feature they support, not how they support it.
- Reduce the number of toolbar controls.
- Train users on meanings of menus and strategies for searching them.
- Investigate non-standard menu organizations.
- If menu items are few, place them directly on menubar.