Guidelines for Choosing Interactive Methods

Choosing the correct components for a task is usually simple. In most cases, a task seems to naturally belong to a component; for instance, scrolling a region with a ScrollBar or choosing a value from a range with a Scale. Each component's general purpose is described in Section 6.1, as well as in the reference section in Chapter 9. In some cases, though, it is difficult to decide between two controls or groups of controls that could perform the same task. The following subsections give some guidelines for choosing among some common similar components:

• Choosing a single-choice component

• Choosing a multiple-choice component

• Choosing among Menus and Panels

• Choosing between Text or Canvas, and a Label

Application Design Principles

6.1.2.1 Choosing a Single-Choice Component

A single-choice component allows the user to select a single item from a group of items. Applications should use a single-choice component to limit the user to one choice; for example, choosing among available pen widths in a drawing program. The available single-choice components are as follows:

• RadioBox

• OptionButton

• List

You should choose a single-choice component based on the number of items to choose among, the space available for the selection area, and the permanence of the selection. For a small number of items, the best component is a RadioBox or an OptionButton. RadioBoxes should usually contain no more than 5 or 6 items. Option Menus, which are connected to OptionButtons, should usually contain no more than 10 to 12 items. If there is very little space available in your application, you should use an OptionButton over a RadioBox, since the OptionButton takes up very little space.

When the number of items to choose from gets larger than a RadioBox or OptionButton can easily handle, you should use a List. You should also use a List when the items to choose from can change. For application consistency, the choices in a RadioBox or OptionButton should not change, but, if they do, you should use an OptionButton over a RadioBox. If a RadioBox or OptionButton choice becomes unavailable, it should be disabled rather than removed. Section 6.3.1.6 describes disabling components in detail.

6.1.2.2 Choosing a Multiple-Choice Component

A multiple-choice control or group of controls allows the user to simultaneously choose multiple items from a group of items. Applications should use multiple-choice components, rather than a series of single-choice actions, where the user may want to select more than one item from a group.

The available multiple-choice components are as follows:

• CheckBox

• List

As with single-choice components, the main factor when choosing which one to use is the number of items in the group. For small groups of fewer than seven static elements, applications should use a CheckBox.

Applications should otherwise use a List. Note that a List component can be used as a single-choice or multiple-choice component.

6.1.2.3 Choosing Among Menus and Panels

Popup Menus should only be considered as shortcuts to application features because they are hidden in the application. Features hidden in Popup Menus are difficult to find for beginning users of an application because they provide no cue to their existence; however, they can provide rapid access to frequently used functionality once the user learns their contents.

Applications should use Popup Menus to allow users to remain focused on their work areas and when there is not enough space in the client area for a Panel of buttons.

Popup Menus contain a set of buttons that can be used in the same way as a Panel of buttons or a Pulldown Menu. The primary difference is availability. A Popup Menu is only visible when requested by the user. At all other times it is hidden, providing no cue to its existence. When the user requests a Popup Menu, the application displays it at the location of the pointer. Buttons and Pulldown Menus, on the other hand, are always visible, but users need to move the focus away from their main work to activate them. Another difference is that buttons take up screen space while Popup Menus do not. Pulldown Menus provide a good compromise in space and availability versus Popup Menus and Panels.

Applications should use a Panel of buttons when the user makes frequent or multiple selections and when space in the client area allows. Whenever the choice between Popup Menus and Panels is difficult, applications should favor Panels.

A good compromise solution to these problems is a TearOff Menu. A TearOff Menu is a Pulldown Menu until the user wants it torn off into a DialogBox. After the Menu is torn off, the user can position it and use it in the same way as a Panel. TearOff Menus are especially useful because they

Application Design Principles

contain a set of PushButtons that are not part of the main function of an application, allowing the user to activate the PushButtons multiple times in a row; for example, a font size Menu in a text editing application. In this case, the user can use the Pull down Menu to change the font size of a single selected word or tear off the Menu into a Panel to perform a number of font size changes in the document. After finishing the font size changes, the user can dismiss the font size Panel.

6.1.2.4 Choosing Between Text or Canvas, and a Label

A Label is a simple mechanism for displaying text or graphics. A Label does not have any mechanisms for the user to edit its contents, or the overhead required for editing. Applications should use a Label for displaying text or graphics that do not need user editing. Applications should use a Text or Canvas when the text or graphics needs to be edited.

On some systems, the contents of a Label are not selectable. If the user needs to select the contents of some noneditable text or graphics, applications should use a Text or Canvas and disable editing rather than using a Label.

6.2 Layout

The previous section described the components that are available for building an application. This section describes how to combine those components into a coherent application that encourages a user's sense of control. The guidelines presented in this section will help you create applications that are both consistent within themselves and with other OSF/Motif compliant applications.

This section discusses the following client area design topics:

• Common client areas

• Grouping components

• Menu design

• DialogBox design

• Designing drag and drop

Design the layout of your application windows according to the natural use order and the natural scanning order of the people who will be using your application.

First design for the natural use order. Consider the tasks that the user will perform with your application. The components should be positioned so that moving among the components is simple and quick while performing the most common tasks-the less pointer movement, the better. This is also true for keyboard traversal-the fewer keystrokes required to perform a task, the better.

The natural scanning order is most important when arranging small groups of components to help the user find the correct component for the task. You should put the most important and most used commands first. In most cases, this order is from left to right and from top to bottom. For users in right-to-left language environments, the natural scanning direction is from right to left and from top to bottom.