Chapter 5. Doing Things:
Actions and Commands This chapter is devoted to the "verbs" in the interface. We've spent a lot of pages talking about overall structure and flow, visual layout, and "nouns" such as windows, text, links, and static elements in pages. Chapter 6 spends even more pages on nouns, and Chapter 7 handles traditional (and a few nontraditional) controls and widgets: things that let users supply information and set state, but that don't actually do much. So now let's talk about buttons and menus. Sounds exciting, doesn't it? Probably not. Desktop interfaces have been using menu bars as long ago as the first Macintosh, and buttons for even longer. What we think of as "buttons" are only a visual rendering of a physical device that predated GUIs anyway. It's true that there is a lot of history here, and many best practices to follow. The standard platform style guides, such as Windows, Macintosh, and PalmOS, generally get you pretty close to a workable UI. Most users depend upon learned conventions to negotiate menus and find buttons, so it behooves you to follow those conventions, even when they feel restrictive or nonsensical. Common functionality like cut, copy, and paste also carries lots of historical baggageif it could be reinvented now, it probably would work differently, but even moderately experienced desktop computer users have learned how it's "supposed to work." The same is true for pop-up menus (context menus), which some users seem to look for everywhere, and other users never look for at all. Drag-and-drop isn't as bound by history, but it absolutely has to work the way users intuitively expect it to, or the illusion of direct manipulation is broken. All that said, you can do some cool things to make your interface less dull and more usable. Your goals should be to make the right actions available, label them well, make them easy to find, and support sequences of actions. There are a few creative ways to do it. First, I'll list the common ways actions are rendered to the user.
Buttons -
Buttons are placed directly onto dialog boxes and pages, and usually are grouped semantically. (See the Button Groups pattern.) They're big, readable, obvious, and extremely easy to use for even the most inexperienced computer users. But they take up a lot of space on the interface, unlike menu bars and pop-up menus.
Menu bars -
Menu bars are standard on most desktop applications. They generally show an application's complete set of actions, organized in a mostly predictable way (such as File, Edit, View). Some actions operate on the entire application, and some operate on individually selected items. Menu bars often duplicate functionality found in context menus and toolbars because they are accessiblescreenreaders can read them, keyboard accelerators can reach them, and so on. (Accessibility alone makes them indispensable in many products.) Menu bars are starting to appear in some web applications, though not as commonly as they appear in desktop software.
Pop-up menus -
Also known as context menus, pop-up menus are raised with a right mouse click or some similar gesture on panels or items. They usually list context-specific, common actions, not all the actions that are possible on the interface. Keep them short.
Dropdown menus -
Users raise these menus by clicking on a dropdown control, such as a combo box, and you can find them on many web pages. However, using dropdown menus for actions is usually a bad idea, since dropdown controls are typically used for setting state, not performing actions.
Toolbars -
The canonical toolbar is a long, thin row of iconic buttons. Often they have other kinds of buttons or controls on them too, like text fields or Dropdown Choosers (see Chapter 7). Iconic toolbars work best when the portrayed actions have obvious visual renderings; when the actions really need to be described with words, try other controls, such as combo boxes or buttons with text labels. Cryptic icons are a classic source of confusion and unusability.
Links -
Links are used mostly on web pages, but are now found on many applications too. They also can be blue underlined words or phrases that merely look like links, but actually are implemented as buttons. The point is that anything blue and underlined looks clickable; people will find and use them. That said, many web application designers now make a conscious effort to reduce potential confusion by sticking with buttons for invoking actions, and links to show other content.
Action panels -
You might know them as "task panes." Action panels are essentially menus that the user doesn't need to post; they're always visible on the main interface. They are a fine substitute for toolbars when actions are better described verbally than visually. See the Action Panels pattern.
Then there are invisible actions, which don't have any labels at all to announce what they do. Users need to know (or guess) that they're there, unless you put written instructions on the UI. Therefore, they don't help with discovery at all. In other words, users can't scan them to find out what actions are possiblewith buttons, links, and menus, the UI actions are available for inspection. Users learn from them. In usability tests, I've seen many users look at a new product and methodically walk down the menu bar, item by item, just to find out what it can do. That said, you almost always need to use one or more invisible actions. People often expect to be able to double-click on items, for example. The keyboard (or the equivalent) sometimes is the only means of access for visually impaired users and people who can't use a mouse. Expert users of some operating systems and applications prefer to work by typing commands into a shell, and/or by using its keyboard actions.
Double-clicking on items -
Users tend to view double-clicking as either "open this item" or "do whatever the default thing is with this item," depending on context. In a graphical editor, for instance, double-clicking on an element often means opening a property sheet or specialized editor for it. Double-clicking an application's icon in most operating systems launches that application.
Keyboard actions -
Keyboard shortcuts, such as the well-known Control-S to save, should be designed into most desktop applications for accessibility and efficient use. The major UI platforms, including Windows, Mac, GNOME, and PalmOS, each have style guides that describe the standard shortcutsand they're all very similar. Additionally, menus and controls often have underlined access keys, which let users reach those controls without mouse-clicking or tabbing. (Type the Alt key, then the underlined letter, to invoke these actions.)
Drag-and-drop -
Dragging and dropping items on an interface usually means either "move this here" or "do this to that." In other words, someone might drag a file onto an application icon to say "open this file in that application." Or she might drag that file from one place in a file finder to another place, thus moving or copying the item. Drag-and-drop is context-dependent, but it almost always results in one of these two actions.
Typed commands -
Command-line interfaces generally allow freeform access to all the actions in the software system, whether it's an OS or an application. I consider these kinds of actions "invisible" because most command-line interfaces (CLIs) don't easily divulge the available commands. They're not very discoverable, though they're quite powerful once you learn what's availablemuch can be done with a single well-constructed command. As such, CLIs are best for users committed to learning the software very well. |
