Command Area

Problem

You need to provide a set of commands to your users in a usable way.

Solution

Group commands together into a unified area of the interface.

Context

• You have more than one command.
• It makes sense for the commands to be grouped together.
• The commands are not already meaningfully placed in context in the interface, or you have determined that a supplemental common command interface would be helpful.

Rationale

Grouping commands into a common area is one of the foundational approaches to software design. This has manifested in many different ways through the years, from menus, to toolbars, to palettes, activity panes, to ribbons, etc. Doing this gives users a common place to go to when they need to find a command.

Even if you have commands in context, it is often helpful and desirable to supply corresponding commands in the command area because users may not be aware of the contextual command (e.g., if it is in a right-click menu), though the Web has started to wear away some of the expectation in that regard.

In addition to providing a common, rationalized grouping of commands, a command area facilitates command discovery, i.e., users will often use them to get a feeling for what commands are available to them if they’re not already familiar with them.

Implementation

Commands are the "verbs" in the interface, i.e., they empower a user to tell the application to do something (save, delete, open, etc.). More often than not, they map to some variation of menus and buttons. For these, each platform has its own conventions, though there are similarities between them. If there is a convention, you’re probably best off following it unless you have a positive reason (other than “to be different”) to break it, and you should do some usability testing if you start exploring new ideas in that way.

How you group commands and what control you chose depends on a lot of factors. General guidelines that apply across the board, though, are to group them into meaningful, user-centric groupings. To do this well requires some knowledge of how users think about the tasks that they would want to perform with your software, so you should try to get that understanding and then look for grouping. Using card sorting with users is a good technique to discover these expected groupings.

Once you have an idea of groupings, you need to pick the tool. This could be a standard hierarchical menu, it could be the Office Fluent Interface, it could be toolbars, palettes, etc. What you pick depends on your overall interface, and it could be some combination. For instance, OmniGraffle is a diagramming tool. It uses both palettes and menus. Visual Studio is an IDE, and it uses tool boxes, property grids, and menus.

Choosing a command area implementation is often where following convention comes in most handy, and sometimes convention is application genre-influenced, e.g., an image or drawing surface application typically has palettes. A Web site mostly has navigation commands, often grouped in top-horizontal or side-vertical menus, though grouping commands in a footer area is becoming common as well.

Most common command area implementations are already available in packaged controls on the target platform and third parties often extend and enhance those that come with the platform. It would be unusual to need to develop your own. If you do, remember the key things for most commands are:

• Icon – most command forms should allow for an icon, an image that visually represents the action.
• Labeling – unless an icon is really universal, you probably need to provide labeling, at least allowing for a tooltip. And for text commands this is obviously required.
• Keyboard Accelerator/Hotkey – it’s fairly common to allow commands to be selected via some keyboard key combination. Showing what these are visually with the command is helpful.
• State Indicator – it is common to have multiple visual states such as normal, hover, depressed, selected, and for navigation commands, visited. Along with these, you sometimes want to provide transition events so that other things can happen during state transition. The most common is the Selected event that occurs when a user selects the command for execution.
• Action – you need to be able to attach an action when the command is selected.
• Target – If the target of the action isn’t known, it may need to be specified.

It is also common to allow for some kind of dynamic creation and binding of a command control to a source that will change the command structure and certain command states based on contextual information, so an implementation would need to take this into account.

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.

ASP.NET

Command Area pattern can be implemented using any of the following ASP.NET controls: WebDataMenu,WebToolbar, WebImageButtons. Check out the samples browser to see it in action.

Silverlight

You can use the NetAdvantage for Silverlight xamWebMenu control for this.

Windows Forms

You can use the NetAdvantage for Windows Forms controls: WinToolbarsManager to implement this pattern. If you download the NetAdvantage for Win Client bundle, you can find a sample in the WinForms sample browser called Ribbon with FormattedTextEditorto see it in action.

WPF

You can implement this pattern using the NetAdvantage for WPF XamRibbon Control. If you download the NetAdvantage for Win Client bundle, you can find a sample in the xamFeatureBrowser called XamRibbon Commands sampleto see it in action.

Tags

Commands, Navigation, Interaction Design, Information Architecture.