The user interface of an application is made up of components that perform two simple functions: presenting the application information to the user, and allowing the user to enter data for the application. Components can be divided into six types: basic controls, field controls, basic groups, layout groups, framing groups, and DialogBox groups. The groups are containers for controls and groups of controls. Groups can be nested.
The component types that should be available in a user interface
toolkit are described in the following lists. The details of these
components are described in the reference section in Controls,
Groups, and Models Reference Pages of this guide. The
correspondence of these components to widgets available in the
OSF/Motif toolkit is described in OSF/Motif
Widgets and Components Correspondence.
Basic Controls
A DialogBox group can either be nested within another group or organizes the contents of a secondary window. Although a DialogBox can contain any component, a simple DialogBox is composed of a Label and a Panel of PushButtons for supplying a response to the DialogBox. The OSF/Motif toolkit provides a number of ready-designed DialogBoxes for common uses: CommandDialog, FileSelectionDialog, MessageDialog, PromptDialog, and SelectionDialog. Several types of MessageDialog are available: ErrorDialog, InformationDialog, QuestionDialog, WorkingDialog, and WarningDialog.
At the highest level, components are organized into MainWindows , Menus, and DialogBoxes. Correctly deciding which component group to use for which parts of an application is one of the most important tasks of an application designer.
Every application must contain at least one MainWindow. The MainWindow can contain a MenuBar, ScrollBars, a command area, a message area, and the client area. The client area of the MainWindow contains the framework of an application. The client area should contain all the components needed to perform the primary actions of the applications. For example, in a text editor application, the MainWindow usually contains a text editing area; in a graphics editor application, the MainWindow usually contains a graphics editing area and the components for changing drawing functions. Components that are used constantly throughout the application should be contained in the MainWindow's client area. Components that are used intermittently or infrequently should be placed in Menus or DialogBoxes.
The advantages of Menus are that they are readily available, quickly accessed and dismissed, and easy to browse through. The most commonly used Menus should be placed in the MenuBar in the MainWindow to increase these advantages. Because Menus are readily available, and quickly accessed and dismissed, they should be used for components that are frequently used. The time delays of bringing up a DialogBox for frequently used components can greatly reduce user productivity. Because Menus are easy to browse through, they should also be used for components that are commonly accessed by most users.
The advantages of Menus also cause some disadvantages. A Menu is a very short-lived component group. It is displayed only while the user makes a selection. Once the user makes a selection, the Menu disappears. So a Menu is not well-suited for making several selections at once.
Adding a TearOffButton to a Menu can allow that Menu to remain available even after a user selection. By activating a TearOffButton, the user changes the current Menu into a simple DialogBox with the same contents as the Menu. A Menu with a TearOffButton allows the user to make multiple selections because the user can cause it to stay posted after a selection. A TearOffButton is useful when it is unclear whether you should include a set of buttons in a Menu or DialogBox.
Menus, other than TearOff Menus, are also modal; that is, while a Menu is posted, the user cannot interact with other elements of the application. Because of this, unless a Menu can be torn off, it should not be used for components that the user may want to have available while interacting with other elements of the application.
The other disadvantage of Menus is that they can only contain buttons and Labels. Menus should be used for performing simple actions and setting values, but they are not suitable for more complicated functions like text entry.
DialogBoxes are used for two general purposes: to present information to the user and to take user input. Applications should use DialogBoxes to present transient information to the user, like warnings, cautions, or conformations to actions. DialogBoxes that present information to the user are called Message DialogBoxes. Message DialogBoxes are often placed on the screen by applications without a request from the user. Because Message DialogBoxes can disrupt a user's work, applications should present constantly updated information in the client area of the MainWindow. Also, applications can present minor cautions, incidental notes, and simple help in the message area of the MainWindow.
The advantages of using DialogBoxes to take user input are that they are long-lived and can contain any components. Because they are long-lived, they can be used to perform more than one action at a time and can remain available while the user interacts with other parts of the application. Applications should use user-input DialogBoxes like small applications. DialogBoxes should be used to perform tasks ancillary to the application, where the user can take more than one action before dismissing the DialogBox. Applications should also use DialogBoxes where the task requires more complicated interaction than is available in a Menu, like file selection.
The table below summarizes the suggested uses for MainWindows, Menus, and DialogBoxes.
For These Cases | Use This Main Component Group | ||
---|---|---|---|
MainWindow | Menu | DialogBox | |
Primary application actions | X | - | - |
Ancillary application actions | - | - | X |
Components used intermittently | - | X | - |
Components used frequently | X | X | - |
Components used seldomly | - | - | X |
Components accessed by most users | - | X | - |
Simple actions | X | X | - |
Complex actions | X | - | X |
Presenting transient information | - | - | X |
Presenting updating information | X | - | - |
Presenting minor information | X | - | - |
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 above, as well as in the reference section in Controls, Groups, and Models Reference Pages. 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:
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:
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. The section
entitled Showing
Unavailable Components describes disabling components in detail.
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:
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.
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 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
Pulldown 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.
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.