In 1979, a computer screen offered exactly 2000 characters per screen (see Figure 22-1), arranged in 25 horizontal rows of 80 characters each. 1-2-3 presented its menu horizontally along the top of the screen, where it consumed only two rows out of the 25 available. This meant that the menu could coexist on the screen with the actual spreadsheet program. Unlike the hierarchical menu programs that came before it, a user didn’t have to leave a productive screen to see a menu. He could enter a menu command right where he was working in the program.
Figure 22-1 The original Lotus 1-2-3, which first shipped in 1979, exhibited a remarkable new menu structure that actually coexisted with the working screen of the program. All other menu-based programs at that time forced you to leave the working screen to make menu selections.
28_084113 ch22.qxp 4/3/07 6:10 PM Page 477
Chapter 22: Menus
477
Lotus used its new menu idiom with great abandon, creating a hierarchical menu structure of remarkable proportions. There were dozens of nodes in the menu tree and several hundred individual choices available. Each one could be found by looking at the top line of the screen and tabbing over and down to the desired selection.
The program differentiated between data for the spreadsheet and a command for the menu by detecting the presence of a backslash character (). If a user typed a slash, the keystrokes that followed were interpreted as menu commands rather than data. To select an item on the menu, all you had to do was read it and type in its first letter preceded by a slash. Submenus then replaced the main menu on the top line.
Frequent users quickly realized that the patterns were memorable, and they didn’t necessarily have to read the menu. They could just type /-s to save their work to disk. They could just type /-c-g-x to add up a column of numbers. They could, in essence, bypass the use of the menu entirely. They became power users, memorizing the letter commands and gloating over their knowledge of obscure functions.
It may seem silly now, but it illustrates a very powerful point: A good user interface enables users to move in an ad hoc, piecemeal fashion from beginner to expert. A given power user of 1-2-3 may have been on intimate terms with a couple of dozen functions, while simultaneously being completely ignorant of several dozen others.
If he had memorized a particular slash-key sequence, he could go ahead and access it immediately. Otherwise, he could read the menu to find those less frequently used ones that he hadn’t committed to memory. We discuss the significance of menus as a means of discovering and learning the functions of an application at length later in this chapter.
But 1-2-3’s hierarchical menu was hideously complex. There were simply too many commands, and every one of them had to fit into the single hierarchical menu structure. The program’s designers bent over backwards to make logical connections between functions in an attempt to justify the way they had apportioned the commands in the hierarchy. In the delirium of revolutionary success and market dominance, such details were easily ignored.
As you might imagine, because of 1-2-3’s success, the mid-1980s were a time of widespread 1-2-3 cloning. The always visible, hierarchical menu found its way into numerous programs, but the idiom was really the last gasp of the character-based user interface in the same way that the great, articulated steam locomotives of the late 1940s were the final, finest expression of a doomed technology. As surely as diesel locomotives completely eliminated all steam power within the span of a decade, the GUI eliminated the 1-2-3-style hierarchical menu within a few short years.
28_084113 ch22.qxp 4/3/07 6:10 PM Page 478
478
Part III: Designing Interaction Details
Drop-down and pop-up menus
Many concepts and technologies had to come together to make the GUI possible: the mouse, memory-mapped video, powerful processors, and pop-up windows. A pop-up window is a rectangle on the screen that appears, overlapping and obscuring the main part of the screen, until it has completed its work, whereupon it disappears, leaving the original screen behind, untouched. The pop-up window is the mechanism used to implement drop-down menus (also called pull-down menus) and dialog boxes.
In modern GUIs, menus are visible across the top row of a screen or window in a menu bar. A user points and clicks on a menu bar and its immediately subordinate list of options appears in a small window just below it. A variant of the drop-down menu is a menu that “pops up” when you click (or more frequently, right-click) on an object, even though it has no menu title: a pop-up menu.
After the menu is open, a user makes a single choice by clicking once or by dragging and releasing. There’s nothing remarkable about that, except that the menus most frequently go no deeper than this. The selection a user makes on the menu either takes immediate effect or calls up a dialog box. The hierarchy of menus has been flattened down until it is only one level deep. In many cases, especially when optimizing interactions for novice users, flattening the organization of user choices (whether they be among commands or objects) can greatly improve the scanability of the user interface.
Arguably the most significant advance of the GUI menu was this retreat from the hierarchical form into monocline grouping. The dialog box, another use of the pop-up window, was the tool that simplified the menu. The dialog box enabled the software designer to encapsulate all the subchoices of any menu item within a single, interactive container. With dialogs, menu hierarchies could flatten out considerably, gathering all the niggling details further down the menu tree into a single dialog window. The deeply hierarchical menu was a thing of the past.
With the higher resolution of GUI displays, enough choices could be displayed on the menu bar to organize all the program’s functions into about a half-dozen meaningful groups, each group represented by a one-word menu title. The menu for each group was also roomy enough to include all its related functions. The need to go to additional levels of menus was made almost superfluous.
(Of course, Philistines and reprobates are always with us, and they have created methods for turning pull-down menus back into hierarchical menus. They are called cascading menus, and although they are occasionally useful, more often they merely tempt the weaker souls in the development community to gum up their menus for little gain. We discuss this in more detail later in this chapter.)
28_084113 ch22.qxp 4/3/07 6:10 PM Page 479
Chapter 22: Menus
479
Menus Today: The Pedagogic Vector
As the modern GUI evolved, two idioms fundamentally changed the role of the menu in the user interface: direct manipulation and toolbars. The development of direct-manipulation idioms has been a slow and steady progression from the first days of graphical user interfaces. Conversely, the toolbar was an innovation that swept the industry around 1989. Within a couple of years, virtually every Windows program had a toolbar filled with butcons. A few years before, nobody had seen a toolbar.
In the same way that a stranger to town may take a roundabout route to her destination while a native will always proceed on the most economical path, experienced users of a program will commonly invoke a function with the most immediate command rather than one that requires intermediate steps. As a result, the most frequently used commands in a program are often invoked by butcons on the toolbar.
Ultimately, menus are commonly needed less and less for functions that are used on a daily basis, and instead become a way of learning about infrequently used tools.
The butcons and other controls on the toolbar are usually redundant with commands on the menu. Butcons are immediate, whereas menu commands remain relatively slow and hidden. Menu commands have a great advantage, however, in their verbal descriptions of functions. This makes them amongst the most useful interaction techniques for the purpose of teaching users about the capabilities of the product. In other words, menus provide a pedagogic vector.
For people to best learn how to use an interactive product, they should be able to examine and experiment without fear of commitm
ent or causing irreparable harm.
The Undo function and Cancel button on each dialog box supports this function well. Contrary to user-interface paradigms of 20 years ago, menus and dialog boxes shouldn’t be the main method by which normal users perform everyday functions.
Many programmers and designers haven’t yet realized this fact, and they continue to confuse the purpose of the menu command vector. Its primary role should be to teach new users, to remind those who have forgotten, and to provide a way to access infrequently used functions.
DESIGN
Use menus to provide a pedagogic vector.
principle
When a user looks at an application for the first time, it is often difficult to size up what that application is capable of. An excellent way to get an impression of the power and purpose of an application is to glance at the set of available functions by way of its menus and dialogs. We do this in the same way we look at a restaurant’s
28_084113 ch22.qxp 4/3/07 6:10 PM Page 480
480
Part III: Designing Interaction Details
menu posted at its entrance to get an idea of the type of food, the presentation, the setting, and the price.
Understanding the scope of what a program can and can’t do is one of the fundamental aspects of creating an atmosphere conducive to learning. Many otherwise easy-to-use programs put users off because there is no simple, unthreatening way for them to find out just what the program is capable of doing.
Toolbars and direct-manipulation idioms can be too inscrutable for a first-time user to understand, but the textual nature of the menus serves to explain the functions. Reading the words “Format Gallery” (see Figure 22-2) is more enlightening to the new user than trying to interpret a butcon that looks like this (although ToolTips obviously help).
Figure 22-2 A menu item reading Format Gallery is likely to be more enlightening to new users than a butcon like this one. But after they become intermediates, it’s a different story altogether.
For an infrequent user who is somewhat familiar with an application, the menu’s main task is as an index to tools: A place to look when he knows there is a function but can’t remember where it is or what it’s called. This works the same way as its namesake, the restaurant menu, which permits him to rediscover that delightful fish curry thing he ordered a year ago, without having to remember its precise name. The drop-down menu lets him rediscover functions whose names he’s forgotten. He doesn’t have to keep such trivia in his head, but can depend on the menu to keep it for him, available when he needs it.
If the main purpose of menus were to execute commands, terseness would be a virtue. But because the main justification of their existence is to teach us about what is available, how to get it, and what shortcuts are available, terseness is really the exact opposite of what we need. Our menus have to explain what a given function does, not just where to invoke it. Because of this it behooves us to be more verbose in our menu item text. Menus shouldn’t say “Open...,”
but rather “Open Report...”; not “Auto-arrange,” but rather “Auto-arrange icons.”
We should stay away from jargon, as our menu’s users won’t yet be acquainted with it.
28_084113 ch22.qxp 4/3/07 6:10 PM Page 481
Chapter 22: Menus
481
Many applications also use the status bar that goes across the bottom of their main window to display an even longer line of explanatory text associated with the currently selected menu item. This idiom can enhance the teaching value of the command vector — if a user knows to look for it. The location ensures that such information will often go unnoticed.
To provide a good pedagogic vector, menus must be complete and offer a full selection of the actions and facilities available in the application. A scan of the menus should make clear the scope of the program and the depth and breadth of its various facilities.
Another teaching purpose is served by providing hints pointing to other command vectors in the menu itself. Repeating button icons next to menu commands and including hints that describe keyboard equivalents teach users about quicker command methods that are available (we discuss this further later in this chapter). By putting this information right in the menu, the user may register it subconsciously.
It won’t intrude upon his conscious thoughts until he is ready to learn it, and then he will find it readily available and already familiar.
Standard menus for desktop applications
Almost every GUI these days has at least a File and an Edit menu in (or near) its two leftmost positions and a Help menu to the right (Mac OS X has a menu named after the in-focus application in the furthest left position — followed by File and Edit).
The Windows, Macintosh, and even the Motif style guides state that these File, Edit, and Help menus are standard. It is tempting to think that this de facto cross-platform standard is a strong indication of the proven correctness of the idiom.
Wrong! It is a strong indication of the development community’s willingness to blithely accept mediocre design, changing it only when the competition forces us to do better. The File menu’s name is the result of implementation model thinking about how our operating systems work, the Edit menu is based on a very weak clip-board, and the Help menu is frequently not terribly helpful and often only contains a single item that is actually directly related to helping users.
These menu conventions can trap us into designing weak user interfaces. The menus on most of our programs may be familiar, but are they good ways to organize functions? Selections like View, Insert, Format, Tools, and Options sound like tools and functions, not goals. Why not organize the facilities in a more goal-directed way?
28_084113 ch22.qxp 4/3/07 6:10 PM Page 482
482
Part III: Designing Interaction Details
Can’t you hear the programmers shouting, “How can you change something that has become a standard? People expect the File menu!” The reply is simple: People may get used to pain and suffering, but that is no reason to perpetuate them. Users will adapt just fine if we change the File menu so that it delivers a better, more meaningful model. The key to figuring out a reasonable menu structure goes back to understanding users’ mental models. How do they think about what they are doing? What terms make the most sense to them? If your users are computer-savvy, and you’re designing a productivity application, it might make sense to stick to recognizable standards, at least at the top level (and then again, it might not). If, however, you’re designing a specialized and purposeful application, the structure might very well need to be different.
All that said, there is obviously still a place for the standard menu structures. In the many situations where it is not appropriate to restructure an application’s menu structure, much good can be done merely by making good choices about how menu standards are applied.
File (or document)
Most users only think of files when they’re forced to understand the implementation model. A much more Goal-Directed term for the menu is “Document.” If your application deals with one primary document or object type, it’s worth considering whether it makes sense to use that for the menu name. For example, in a music sequencer, “Song” would be a much more user-friendly term than “File.” We assure you, there’s nothing worse to be thinking about when making music than a computer’s file system.
In Chapter 17 we described a better File (or Document) menu. One useful feature we didn’t mention there is the Most Recently Used list on Microsoft applications (see Figure 22-3).
Edit
The Edit menu contains facilities for selecting, cutting, pasting, and making modifications to selected objects (though if there are a lot of functions to do this, they should be grouped in a separate Modify or Format menu). Don’t use the Edit menu as a catch-all for functions that don’t seem to fit anywhere else.
28_084113 ch22.qxp 4/3/07 6:10 PM Page 483
Chapter 22: Menus
483
Figure 22-3 The File menu from Microsoft Word shows off the excellent Most Recently Used (MRU) list. In Chapter 17, you saw how to reconstruct the first six items so that they better reflect the user’s mental model, rather than following the technically faithful implementation model as shown here.
Windows
The Windows menu is for arranging, viewing, and switching between multiple windows opened by the program. It can also offer tools for laying out multiple documents onscreen simultaneously. Nothing else should go on this menu. It should be noted that unless you have a multiple document interface (MDI), this menu is seldom necessary.
Help
Today’s Help menus tend to reflect poorly designed and implemented help systems.
We talk much more about help in general in Chapter 25, but suffice to say, this menu should contain a variety of methods for helping people learn to use your application. One thing sorely lacking on most Help menus is an item labeled Shortcuts that
28_084113 ch22.qxp 4/3/07 6:10 PM Page 484
484
Part III: Designing Interaction Details
explains how to go beyond relying on the menus. It could offer pointers on more powerful idioms such as accelerators, toolbar buttons, and direct-manipulation idioms.
Optional Menus
The following menus are commonly used, but considered optional in most style guides. An application of moderate complexity is likely to make use of at least some of these menus.
View
The View menu should contain all options that influence the way a user looks at the program’s data. Additionally, any optionally displayed structural interface elements such as rulers, toolbars, grids, drawers, sidebars, or palettes should be controlled here.
Insert
The Insert menu provides the facility to introduce new objects in a document. In a word processor, appropriate examples include inserting tables, graphs, and symbols. In a music sequencer, appropriate examples include inserting new instruments, effects, and key changes.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 64