Task Pane

Problem

You need to present many actions and a menu or a toolbar aren’t a good fit.

Solution

Present a large group of related actions on a UI panel that's richly organized and always visible.

Context

You could put them into a menu, but maybe you don't have a menu bar at all, or you'd rather make the actions more obvious. Same for pop-up menus; they're just not visible enough. Your users may not even realize the pop-up menus exist.

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 top level menu names -- such as File, Edit, View, Tools, or Format -- then you might want a different presentation altogether.

They are also a good choice when you need to provide informational guidance around the available commands, or when you need to show additional context for the commands. This pattern can take up a lot of screen space, so it's not usually a good choice for small devices.

Rationale

The "Context" section already hinted at the two main reasons for using action panels: visibility and freedom of presentation.

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!

Sometimes the application can add valuable contextual information to the commands you need to execute. Task panes are a good way to have that information available.

Implementation

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 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.

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

If you categorize the actions, consider using a task-centered approach. Group them according to what people intend to do. In the Powerpoint example, for instance, there's an "Open a presentation" group, plus several groups for creating new slideshows.

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.

The pane can be on the left or on the right, and it depends on your application which is the best place to put it. Windows Explorer uses it on the left, Office on the right. The reason why the Office team decided to put it on the right was that in conflicted with the PowerPoint left pane, and it caused the document to shift when the task pane was opened/closed.

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 better 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. Feel free to experiment. However, usability-test it to make sure users actually see the actions as clickable things, not ordinary text or pictures.

The Office War Story

Microsoft Office did extensive use of Task Panes, but that changed in Office 2007 where they were mostly replaced with the Ribbon.

As Office become more complex, different teams started using the Task Pane as the place where they could add whatever they needed. This made it easier for each team, but it they lost the overall picture. Every feature would replace the previous Task Pane of the previous feature (because only one could be up at once.) Taks Panes were used for very different things. Some of them were like wizards with multiple pages, others were really dialog boxes, some of them were just a menu of two commands with a bunch of explanatory text around them. No one was in charge of reconciling all of the Task Panes, how to find related functionality in the old UI system or, how to use two features at once..

Some products actually did a very good job with them. The overall interaction flow of PowerPoint XP is markedly improved over PowerPoint 2000 because of careful use of task panes in the layout, transition and slide design among others.

There is agreement that the worse feature of the Office Task Panes was the navigation UI at the top which only navigated between task panes. Since they were deliberately a subset of the overall UI, it was a navigation short circuit and valueless. Office 2007 eliminated it.

As a summary, task panes like the ones in Windows Explorer are a nice way to use them. If you find yourself doing something more complex, evaluate other alternatives.

Help Me Get There

Infragistics has some tools that can jumpstart your efforts to implement this pattern. Broken down by technology, they are as follows.

Windows Forms

You can use the NetAdvantage for Windows Forms WinExplorerBar to implement this pattern. Furthermore, you can use the WinDockManager with some arbitrary task based content to build out the task pane pattern.

WPF

You can implement this pattern using the NetAdvantage for WPF xamDockManager control along with some arbitrary task based content.

Sources

Jennifer Tidwell, Designing Interfaces

Jensen Harris, New Rectangles to the Rescue?

Jensen Harris, The Future of Task Panes

Tags

Commands.