[Contents] [Index] [Next] [Previous]

Interaction


This section gives guidelines for creating applications with consistent interactions. When an application behaves as expected and the user is not surprised by the results of the actions, the user can complete tasks quicker. The following subsections present the following guidelines for good application interaction:

Supplying Indications of Actions

The first step to consistent interaction is to provide cues to the result of every action. This means that actions of components should be indicated by the component's shape, label, and graphics. It also means that the actions and interactions of components should remain consistent, so the user always knows what to expect.

Lastly, it means that interactions should be simple. As interactions become complicated, it also becomes difficult to visually represent the interaction. Complicated interactions and components create the possibility for more errors. Even the most complicated concepts can be clarified by careful organization, so, if your application's interactions seem complicated, consider reorganizing them for simplicity.

Using Common Components

Users expect components to behave consistently across all applications. PushButtons always perform an action. OptionButtons always provide selections. Because of this, when users want to perform an action, they look for a PushButton, usually in a Menu. They do not look for an OptionButton. You should use the components that are provided when appropriate, rather than create new ones. You should not alter the look of a component so drastically that its type is unrecognizable.

Using Intuitive Labels

One of the best indicators of the action of a component is its Label. The Label can be either text or a graphic. You should choose your Labels carefully to indicate the action of each component.

Components that perform actions should be labeled with active verbs. Components that present options should be labeled with nouns. You should also label component groups, including Panels, with nouns to indicate the contents of the group.

Consider the use of graphics as Labels with two cautions. Graphic Labels cannot be nouns or active verbs, so choose a graphic whose meaning is clear in the context of the component. Also remember that, while graphic symbols are very language independent, they can be highly culture specific. In some cultures, a mailbox graphic can indicate a mailer action; but, since mailboxes are not common in all cultures, an envelope graphic may be better, or you can provide a mechanism for changing the graphic based on the locale.

Using Graphics to Show Action

Many components also include a small graphic symbol following the Label to indicate the action of the component. CascadeButtons should use an arrow graphic that points in the direction the cascading Menu will appear. OptionButtons should use a rectangle graphic to distinguish them from PushButtons.

Any component that needs more information to complete its action should include an ellipsis following the Label. This additional information should be requested in a DialogBox. The ellipsis should not be used to indicate that the component will post a DialogBox. The ellipsis should be included only if the purpose of the DialogBox is to gather more information needed to complete the requested task. For example, the Menu choice Print would use an ellipsis if a DialogBox is posted requesting print characteristics prior to the printing action, but the Menu choice Help would not use an ellipsis even though the help information is presented in a DialogBox.

All previously mentioned graphics should follow the text or graphic of the Label. In left-to-right language environments, the graphic should be on the right. In right-to-left language environments, the graphic should be on the left. Note that the graphic indicating the state of a ToggleButton precedes the Label in a left-to-right language environment.

Showing Default Actions

Your application should use default values for common settings or obvious selections. Default values should be shown in the on state. For example, the default value for a Text area should be in the Text area in the selected state whenever text entry is requested; the default selection in a List should be set in the selected state whenever a list selection is requested; or the default RadioButton should be filled in a Panel at application start-up time. In any case, once the state is changed, the new state should take the place of the default until the state is reset. Your application can decide whether to save its state after being closed.

Groups of controls, such as a DialogBox, can also have a default action. The default action is usually activated by pressing [Enter] or . The default action of a component group should be distinguished from the other selections by an extra border as shown below.

The OK PushButton should be the default PushButton in modal DialogBoxes and modeless DialogBoxes that are transient. The Apply PushButton should be the default PushButton in a modeless DialogBox that is likely to be displayed for multiple actions.

Using the keyboard to navigate through the PushButtons, the button with the location cursor should become the default PushButton. This ensures that pressing [Enter] or over a PushButton invokes the correct PushButton. When the location cursor leaves the PushButtons, the original default button should once again become the default.

Avoiding Component Modes

A component has modes when its action changes based on some previous action or the state of the application. This is very confusing to the user, who was expecting the original action of the component. Components in your application should not have modes. Your application should use multiple components rather than modal components.

Showing Unavailable Components

As the state of your application changes, certain components become inappropriate. For example, the Minimize selection in a window Menu is inappropriate when the window is already minimized. In such cases, you should make the inappropriate components unavailable. This is also called disabling the components. Disabled components should be visually deemphasized, usually by graying the Label of the component.

You should not remove unavailable components from the application client areas. The components should remain visible to remind the user of their existence and to ensure application consistency. A disabled Menu element is shown below.

You should disable Menu items and components to help avoid errors. In general, you should disable the lowest level component that results in an irreversible error state. For example, consider a graphics editor that has a DialogBox that is used for aligning selected graphics objects. If the user might want to see the choices in the DialogBox even if the choices are not available, this DialogBox should be displayable at all times; its Menu item should not be disabled. If there are no graphics objects to align, the DialogBox should still be displayed, but its OK and Apply buttons should be disabled. Once graphics objects are selected, the OK and Apply buttons should become enabled.

Menu items that are inappropriate and that result in error messages should be disabled. Some examples are the Edit Menu's Cut and Copy actions when nothing is selected. The Edit Menu's Undo entry should be disabled if the last operation cannot be undone.

Menu items that perform no action need not be disabled. For example, the New entry in the File Menu need not be disabled immediately after it is invoked. It can be selectable repeatedly, even though it performs no new action, because it does not result in an error state.

A Menu item that displays a modal DialogBox should be disabled if it would cause an error either on display of the box, or on clicking the OK or Apply buttons in the DialogBox. Since the DialogBox is modal, nothing can be changed in the application to correct the error until the box is dismissed, and it should not be displayable until the application is in a state that makes the action of the DialogBox possible.

Menu items that display modeless DialogBoxes should never be disabled. If a box is modeless, the user can change the state of the application at any time to make the DialogBox useful. If the action cannot be completed because some necessary information is not yet available, then the OK and Apply buttons should be disabled.

After a TearOff Menu is torn off, an application can disable elements that are not appropriate in the torn off state. Elements in a torn off Menu can be disabled in the same manner as elements in any other Menu or DialogBox.

You should avoid frequently disabling and enabling components in situations where the state change would cause a distracting flashing. For example, editing a Text component in a DialogBox can cause some buttons to be inappropriate at each invalid text value. In this case, you should display an error message if the OK or Apply button is clicked for an inappropriate text value. Of course, the error message should explain the valid text values.

Providing Feedback

Another important element to user interaction is providing feedback about the current state of the application. This is done, as described in the previous section, by using labels and graphics and by keeping the interface consistent. Your application should also dynamically indicate the state of the application's actions. For example, the mouse pointer shape changes to indicate when and where special actions can occur. Input Models describes mouse pointer shapes in detail. Other ways to provide the user feedback are described in the following subsections.

Showing Progress

If an action takes a long time to complete, the user may mistake the delay to mean that the system or the application stopped working. For actions that take a long time to complete, your application should indicate that there will be a delay with a WorkingDialog. If your application can track the progress of long actions, it should try to update the WorkingDialog with the progress of the action.

Providing Warnings

Certain actions can cause destructive results, such as closing an application before saving changes in the current file. Applications should not disallow such destructive actions; instead, they should warn the user of the consequences with a WarningDialog. The WarningDialog must allow the user to cancel the destructive action. Note that too many WarningDialogs can be disruptive to the user's main task. WarningDialogs should be reserved for truly destructive actions. For destructive actions that can easily be recovered, applications should provide undo actions to reverse them; for example, the Undo element of the Edit Pulldown Menu.

Providing Help

Even in the most intuitive application, the purpose of a component or the way to do a task can be hard to figure out for a new user. Your application should provide a help mechanism for all of its aspects. The section entitled MenuBar describes the most common base for a help mechanism, the Help Pulldown Menu on the MenuBar. Context-sensitive help should also be available by using .

Allowing User Flexibility

Good user-application interaction should also allow user flexibility. No matter how well your application is designed, some users will not like parts of it. They will want to change some elements of it; for example, from simple elements like the colors and fonts to complicated elements like the default values. You should allow users to adjust elements of your applications because it increases their sense of control over the applications. You should consider the following attributes of your applications for user customization:

The exact list of attributes you should allow the user to customize depends on your application.