Settings
If you have a Settings menu in your application, you are making a commitment to a user that anytime he wants to alter a setting in the program he will easily find the way to do it here. Don’t offer up a settings menu and then scatter other setting items or dialogs on other menus. This includes printer settings, which are often erroneously found on the File menu.
Format
The Format menu is one of the weakest of the optional menus because it deals almost exclusively with properties of visual objects and not functions. In a more object-oriented world, properties of visual objects are controlled by more visual direct-manipulation idioms, not by functions. The menu serves its pedagogic purpose, but you might consider omitting it entirely if you’ve implemented a more object-oriented format property scheme.
28_084113 ch22.qxp 4/3/07 6:10 PM Page 485
Chapter 22: Menus
485
The page setup commands that typically reside on the File menu should be placed here. (Notice that page setup is very different from printer setup.) Tools
The Tools menu, sometimes less clearly called the Options menu, is where big, powerful functions go. Functions like spell checkers and goal finders are considered tools. Also, the Tool menu is where the hard-hat items should go.
Hard-hat items are the functions that should only be used by real power users.
These include various advanced settings. For example, a client-server database program has easy-to-use, direct-manipulation idioms for building a query, while behind the scenes the program is composing the appropriate SQL statement to create the report. Giving power users a way to edit the SQL statement directly is most definitely a hard-hat function! Functions like these can be dangerous or dislocating, so they must be visually set off from the more benign tools available. Another possible approach is to place them in an Expert or Advanced menu, to the right of the more benign Tools menu, which Apple has done in iPhoto, for example, though some of the functions there may be improperly placed.
Menu Idioms
Over the years, simple menus have been embellished with new and more complex behavioral idioms. Some have their uses, and others simply get in the way. This section discusses these idioms and their appropriate uses.
Cascading menus
One variant of the standard drop-down menu provides a secondary menu when a user selects certain items in the primary menu. This mechanism, called a cascading menu (see Figure 22-4), presents some serious issues for ease of use.
Where standard drop-down menus provide clear, easy-to-navigate monocline grouping, cascading menus move us into the complex territory of nesting and hierarchies. They not only make it much more difficult for users to locate items, but they also require well-coordinated mouse movements in two dimensions to navigate them smoothly. (If you trace the path required to select an item in a multilevel cascading menu [such as the Windows Start menu], you will notice that it quite literally takes the form of a path through a maze).
28_084113 ch22.qxp 4/3/07 6:10 PM Page 486
486
Part III: Designing Interaction Details
However, cascading menus are not entirely without worth. They also allow menus to contain much larger command sets, and they provide a hierarchical method of organizing these command sets. As useful as this may sound, please pay close attention to your users before choosing to employ this idiom.
It should be clear that cascading menus should only be employed in sophisticated sovereign applications for rarely used functions or as a secondary command vector for something more directly provided in the interface. Also, if you implement cascading menus, be sure to allow for a wide threshold in mouse movement, so the submenu doesn’t disappear.
Figure 22-4 This is an example of a cascading menu from Microsoft Word 2003.
Cascading menus make it difficult for users to find and browse the command set, but they do allow menus to usefully contain much larger command sets.
Menus
With Office 2000, Microsoft introduced adaptive menus, which display only those items accessed most frequently by a specific user (see Figure 22-5). This menu idiom was enabled by default in Office 2000 and 2003, but Office 2007 marked a departure from this approach (and menus in general) in favor of the ribbon bar, which we discuss below and in Chapter 23.
With adaptive menus, Microsoft attempted to make their products seem simpler and easier by hiding those items that a user never accesses. To see the hidden menu items, users are required to click or hover on an icon at the bottom of the menu.
When displayed, the previously hidden items are interspersed with the originally shown items.
28_084113 ch22.qxp 4/3/07 6:10 PM Page 487
Chapter 22: Menus
487
The adaptive menu is well intended, and we certainly applaud the attempt to customize a user interface based upon usage behavior. Unfortunately, the idiom is annoying and severely compromises user effectiveness. Adaptive menus significantly increase the amount of work performed by users as the idiom runs contrary to the two primary roles of a menu system: to teach users about the breadth and depth of application functionality and to provide access to less-frequently used functions.
Figure 22-5 These images show an expanding menu from PowerPoint 2003. On the left is the menu in its default state, showing a subset of commands based upon usage patterns. The middle image shows the hover state, and on the right is the full menu that is displayed after clicking the expand button.
It’s worth noting that usability studies support this assessment. In a 1989 study, subjects took a significantly longer time to complete tasks with adaptive menus than with static menus, and 81% reported preferring static menus to adaptive menus.1 We would caution readers about interpreting these findings to mean that users will never feel well supported by adaptive interfaces. Rather, we suggest that this particular application of adaptability was directly at odds with the purpose of menus.
The ribbon
In Office 2007, Microsoft introduced a new command control — the ribbon, a tabbed panel at the top of the application window that combines the menus and toolbars into a single unified structure (see Figure 22-6). The idea behind the ribbon is to combine the visually expressive and pliant characteristics of toolbar buttons and butcons with the verbose and more explicit and comprehensive depiction of functionality of a menu system.
28_084113 ch22.qxp 4/3/07 6:10 PM Page 488
488
Part III: Designing Interaction Details
Figure 22-6 This is the ribbon from Microsoft PowerPoint 2007. This new interface idiom is a combination between a menu system’s hierarchical organization and the more direct and visual presentation of a toolbar.
Unlike adaptive menus, the ribbon appears to have been designed with the strengths and uses of both menus and toolbars. As with a menu, clicking through the tabs of the ribbon provides a good overview of the capabilities of an application (though the visual complexity and the fact that some items are vertically stacked somewhat compromises its scanability). Like a toolbar, the ribbon provides fairly direct and visual access to functions, though a user is sometimes required to change tabs to find the right button. This is somewhat mitigated by the fact that a contextual toolbar is provided immediately next to a selected item in the document workspace (more on this in Chapter 23), and the tabs are meant to change automatically to provide access to appropriate tools. While the ribbon idiom is appealing and intriguing, it seems that this is not entirely effective in initial releases of Office 2007.
After repeated use, we find ourselves continually hunting for commonly used functions. Perhaps this will improve — at the time of writing, Office 2007 has only been available for six months.
Bang menus
In the early days of the Mac and Windows, some applications featured a menu variant that has, for good reason, fallen out of favor: the immediate menu or bang menu. In programmer’s jargon, an exclamation mark is a bang, and, by convention, top-level
immediate menu items were always followed with a bang.
As the name implies, it is a menu title — directly on the menu bar next to other menu titles — that behaves like a menu item. Rather than displaying a drop-down menu for subsequent selection, the bang menu causes a function to execute right away! For example, a bang menu title for printing would be called Print!.
This behavior is so unexpected that it generates instant disorientation (and sometimes even anger). The bang menu title has virtually no instructional value (except perhaps through shock value). It is dislocating and disconcerting. The same immediacy on a toolbar button or butcon bothers nobody, though. The difference is that butcons on a toolbar advertise their immediacy because they are known by convention to be imperative controls. This is a classic example where breaking from
28_084113 ch22.qxp 4/3/07 6:10 PM Page 489
Chapter 22: Menus
489
standard and convention without sufficient cause can result in serious cognitive friction for users. Immediate commands belong in toolbars.
Disabled menu items
An important menu convention is to disable (make nonfunctional) menu items when they are unavailable in a given state or not relevant to the selected data object or item. The disabled state is typically indicated by lightening or “graying out” the text for the item in the menu. This is a useful and expected idiom — it helps the menu become an even better teaching tool, as users can better understand the context in which certain commands are applicable.
DESIGN
Disable menu items when they are not applicable.
principle
Checkmark menu items
Checkmarks next to menu items are usually used for enabling and disabling aspects of the program’s interface (such as turning toolbars on and off) or adjusting the display of data objects (such as wire frame versus fully rendered images). This is an idiom easily grasped by users and is effective because it not only provides a functional control but also indicates the state of that control.
This idiom is probably best used in programs with fairly simple menu structures. If the application is more complex and sophisticated, the menu space will be sorely needed, and opening and scrolling through a menu to find the right item may become laborious. If the attributes in question are frequently toggled, they should also be accessible from a toolbar. If they are infrequently accessed and menu space is at a premium, all similar attributes could be gathered in a dialog box that would provide more instruction and context (as is commonly required for infrequently used functionality).
A checkmark menu item is vastly preferable to a flip-flop menu item that alternates between two states, always showing the one currently not chosen. The problem with the flip-flop menu is the same issue we identified with flip-flop buttons in Chapter 21 — namely that users can’t tell if it is offering a choice or describing a state. If it says Display Toolbar, does that mean tools are now being displayed or does it mean that by selecting the option you can begin displaying them? By making use of a single checkmark menu item instead (Status bar is either checked or unchecked), you can make the meaning unambiguous.
28_084113 ch22.qxp 4/3/07 6:10 PM Page 490
490
Part III: Designing Interaction Details
Icons on menus
Visual symbols next to text items help users recognize them without having to read, so they can be identified faster. They also provide a helpful visual connection to other controls that do the same task. In order to create a strong visual language, a menu item should show the same icon as the corresponding toolbar butcon.
DESIGN
Use consistent visual symbols on parallel command vectors.
principle
Windows provides powerful tools for putting graphics in menus. Too few programs take full advantage of this opportunity for providing an easy, visual learning trick.
For example, the applications in Microsoft’s Office suite all use an icon depicting a blank sheet of paper to indicate the New Document function on their toolbars. The same icon is used in the File menu to the left of the New... menu item. Users soon make the connection, probably without even thinking about it. Microsoft Office applications have done an excellent job incorporating graphics into their menus, as shown in Figure 22-3.
Accelerators
Accelerators or “keyboard shortcuts” provide an easy way to invoke functions from the keyboard. These are commonly function keys (such as F9) or combinations involving meta-keys (e.g., Ctrl, Alt, Option, and Command). By convention, they are shown to the right of drop-down menu items to allow users to learn them as they continue to access a menu item. There are standards defined for Windows, Mac OS X, and other platforms, but their implementation is up to the individual designer, and they are too often forgotten.
There are three tips for successfully creating good accelerators: 1. Follow standards.
2. Provide for their daily use.
3. Show how to access them.
Where standard accelerators exist, use them. In particular, this refers to the standard editing set as shown on the Edit menu. Users quickly learn how much easier it is to type Ctrl+C and Ctrl+V than it is to remove their mouse hands from the home row to pull down the Edit menu, select Copy, then pull it down again and select
28_084113 ch22.qxp 4/3/07 6:10 PM Page 491
Chapter 22: Menus
491
Paste. Don’t disappoint them when they use your program. Don’t forget standards like Ctrl+P for print and Ctrl+S for save.
Identifying the set of commands that will be needed for daily use is the tricky part.
You must select the functions that are likely to be used frequently and ensure that those menu items are given accelerators. The good news is that this set won’t be large. The bad news is that it can vary significantly from user to user.
The best approach is to perform a triage operation on the available functions.
Divide them into three groups: Those that are definitely part of everyone’s daily use, those that are definitely not part of anyone’s daily use, and everything else. The first group must have accelerators and the second group must not. The final group will be the toughest to configure, and it will inevitably be the largest. You can perform a subsequent triage on this group and assign the best accelerators, like F2, F3, F4, and so on, to the winners in this group. More obscure accelerators, like Alt+7, should go to those least likely to be part of someone’s everyday commands.
Don’t forget to show the accelerator in the menu. An accelerator isn’t going to do anyone any good if they have to go to the manual or online help to find it. Put it to the right of the corresponding menu item, where it belongs. Users won’t notice it at first, but eventually they will find it, and they will be happy to make the discovery as perpetual intermediates (see Chapter 3). It will give them a sense of accomplish-ment and a feeling of being an insider. These are both feelings well worth encouraging in your customers.
Some programs offer user-configurable accelerators, and there are many instances where this is a good idea, and even a necessity, especially for expert users. Allowing users to customize accelerators on the sovereign applications that they use most of the time really lets them adapt the software to their own style of working. Be sure to include a Return to Defaults control along with any customization tools.
Access keys
Access keys or mnemonics are another Windows standard (they are also seen in some Unix GUIs) for adding keystroke commands in parallel to the direct manipulation of menus and dialogs.
The Microsoft style guide covers access keys and accelerators in detail, so we will simply stress that they should not be overlooked. Mnemonics are accessed using the Alt key, arrow keys, and the underlined letter in a menu item or title. Pressing the Alt key places the application into mnemonic mode, and the arrow keys can be used
28_084113 ch22.qxp 4/3/07 6:10 PM Page 492
492
Part III: Designing Interactio
n Details
to navigate to the appropriate menu. After it opens, pressing the appropriate letter key executes the function. The main purpose of mnemonics is to provide a keyboard equivalent of each menu command. For this reason, mnemonics should be complete, particularly for text-oriented programs. Don’t think of them as a convenience so much as a pipeline to the keyboard. Keep in mind that your most experienced users will rely heavily on their keyboards; so to keep them loyal, ensure that the mnemonics are consistent and thoroughly thought out. Mnemonics are not optional.
Menus on other platforms
Most of the preceding discussion is based in pattern and convention for traditional desktop software platforms. Of course, things change a bit when you consider other platforms. On devices such as mobile phones and palmtops, menus must often be relied upon as a primary command vector. While applications on handhelds typically do provide some functions in the form of buttons, due to screen real-estate limitations, toolbars and more direct idioms are not always possible, so the only way to provide access to the vast majority of functions is through a menu system.
PalmOS and Windows Mobile feature drop-down menus much like those found on modern desktop GUIs, complete with accelerators. This is, by and large, a useful translation, but it’s worth considering that some idioms don’t work as well with smaller screens, styluses, and four-way rocker switches. First of all, cascading menus are to be avoided at all costs. It is next to impossible to fit two adjacent open menus on the screen, and having one overlay another can cause serious confusion and dislocation for a mobile user. Second, due to space constraints, it may not be feasible to include icons on menus, despite the fact that they may be of great utility to a walking user who may find an icon easier to identify than a word.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 65
