Action Panel

Or maybe your set of possible actions is too complex even for a menu. Menus are best at showing a flat set of actions (since pull-right menus, or cascading menus, are hard for some users to manipulate), in a very simple, linear, one-line-per-item presentation. If your actions need to be grouped, and if those groups don't fit the standard toplevel menu names -- such as File, Edit, View, Tools, or Format -- then you might want a different presentation altogether.

This pattern can take up a lot of screen space, so it's not usually a good choice for small devices.

By placing the actions out on the main UI, and not hidden inside a traditional menu, you make those actions fully visible to the user. Really, action panels are menus, in the generic sense; they just aren't found in menu bars, dropdowns, or pop-ups. Users don't have to do anything to see what's on an action panel -- it's right there in front of them -- so your interface is more discoverable. This is particularly nice for users who aren't already familiar with the traditional document model and its menu bars.

There are many, many ways to structure objects on an interface: lists, grids or tables, hierarchies, and just about any custom structure you can devise. But button groups and traditional menus only give you a list (and not a very long one). Action panels are freeform -- they give you as much freedom to visually organize verbs as you have for nouns. Use it wisely!

This is one of the places where web design conventions were "back-ported" into desktop applications. Since early web applications couldn't depend on dynamically shown menus, and they certainly couldn't use the browser's menu bar, page designers found other ways of presenting action menus. Vertical columns of links seemed to work fine. (The fact that they're links, not buttons, is sort of irrelevant; if they're labeled as verbs, and if they appear to perform actions, who cares about their implementation? Users don't.)

Set aside a block of space on the interface for the action panel. Place it below or to the side of the target of the action. The target usually is a list, table, or tree of selectable items, but it also might be the Center Stage, like the Powerpoint example in Figure 5-6. Remember that proximity is important. If you place the action panel too far away from whatever it acts on, users may not grasp the relationship between them.

The panel could be a simple rectangle on the page. It could be one of several tiled panels on the page, perhaps a Movable Panel, a "drawer" in Mac OS X, or even a separate window. That choice depends on the nature of your application. If it's closable, then make it very easy to reopen, especially if those actions are present only on the action panel and aren't duplicated in a menu!

Odds are good that you'll need to show different actions at different times. The contents of the action panel may depend on the state of the application (e.g., are there any open documents yet?), on the items selected in some list somewhere, or other factors. Let the action panel be dynamic. The changes will attract the user's attention, which is good.

Structuring the actions

Next, you need to decide how to structure the actions you need to present. Here are some ways you could do it:

• Simple lists
• Multicolumn lists
• Categorized lists, like the Powerpoint example above
• Tables or grids
• Trees
• Closable Panels
• Any combination of these in one panel

Still, try to present these groups linearly. Imagine reading the actions aloud to someone who can't see the screen -- can you proceed through them in a logical fashion, with obvious start and end points? That, of course, is how a blind user would "hear" the interface.

Incidentally, you can also put controls on an action panel, like a text field next to a "Search" button.

Labeling the actions

For each action's label, you could use text, icons, or both, depending on what best conveys the nature of the actions. In fact, if you use mostly icons, then you end up with... a traditional toolbar! (Or a palette, if your UI is a visual builder-style application.)

Text labels on an action panel can be longer than those on a menu or a button. You can use multiline labels, for instance -- no need to be overly parsimonious with words here. Just remember that longer, more descriptive labels are betetr for first-time or infrequent users, who need to learn (or be reminded of) what these actions do. The extra space spent on long labels may not be appreciated in dense high-performance interfaces used mostly by experienced users. If there are too many words, even first-time users' eyes will glaze over.

There's often no need to make the actions look like buttons, even if they're implemented as buttons. Phrases written in blue text communicate clickability, since they look like links on a web page; you could enhance the effect by underlining them when the mouse rolls over them. This is what Microsoft does in its interfaces that use action panels. Feel free to experiment. However, usability-test it to make sure users actually see the actions as clickable things, not ordinary text or pictures.

This screenshot of the Windows Explorer shows a directory of pictures attached to an action panel. Microsoft calls this feature a "Task Pane." The panel is composed of closable subpanels (see the Closable Panels pattern in Chapter 4), each of which contains a manageable handful of related actions.

Note that the first two sections, Picture Tasks and File and Folder Tasks, are completely task-oriented: they're phrased as verbs (View, Order, Print, and Copy), and they anticipate things users will commonly want to do. You might recall that in Chapter 1, we talked about organizing interfaces according to lists of objects, actions, categories, and tools. The first two sections are fine examples of lists of actions. But the third section in this panel, "Other Places," is a list of objects instead.