[ Previous | Next | Contents | Glossary | Home | Search ]
Motif and CDE 2.1 Style Guide

Placing the User in Control of the Interface

Users should be able to interact with the computer and feel that they are in control of their tasks. The following design principles address user control:

  1. Avoid program-driven sequences that prompt the user through fixed steps.

    For example, instead of providing fixed steps in which the user can choose only from a set series of choices and consequences, let the user move throughout the interface, choosing from a range of choices that can lead to numerous subsequent choices and consequences.

  2. Provide alternatives.

    Let the user take alternative courses of action; do not limit a user's capabilities by imposing any preconceived notions of the "correct" sequence for accomplishing a task.

  3. Design with a "no user errors" philosophy.

    Use informational messages or help information to represent errors as application limitations. Avoid representing events as errors that could be attributed to the user.

Adopting the User's Perspective

Effective design starts with adopting the user's point of view. Application developers tend to see an application as the implementation of functions; users see an application in terms of the tasks they need to perform.

Good design is rooted in an understanding of the user's tasks. Well-designed applications solve users' problems, make their work easier, and offer them new capabilities. The following design principles address the user's perspective:

  1. Involve users in the design process.

    Input from users can help determine both appropriate functions and the methods for presenting them. Involve users as early as possible in the design process because as the design progresses, the possibilities for change decrease.

    You do not need a working prototype to involve users. You can involve users while you write specifications. At this stage, you can watch users work in order to understand the environment in which your application will be used. Talk to users about their work, their current tools, and their goals for new tools. For example, if you are designing an application to create and display charts and graphs during meetings, attend meetings at customer sites, see how charts and graphs are used, and interview meeting participants to learn what they would like in a new tool. Once you have a working prototype of your application, invite users to test it to see if your interface meets the goals you established for it.

  2. Use your application in real situations.

    Using an application provides critical insights into user interface problems. Before you create the interface for your application, use similar applications, even competitive applications, to help you understand the user's tasks. Observing the user's reaction to various interfaces will also provide important feedback. Acquiring experience with the application may be difficult and time consuming, but it is a worthwhile exercise.

    When you use your own application, you become a user yourself. However, be aware that not all users think like you. You may not represent the user for which the application was designed.

Providing Modes

A mode is a state of the application in which only certain actions are available to the user. That is, modes restrict the user's options and limit an application's response to the user's actions.

Modes require additional learning, slow down users, and create confusion when the same user action causes different results in different modes. However, modes are useful in a number of situations. Modes extend the capabilities of input devices by letting several actions be accomplished with the same technique, key, or button; and they help an experienced user perform a series of actions quickly. Modes are also useful when there are a set of steps that must be performed in sequence, or if the user does not have permission to perform certain actions.

Provide modes when:

  1. The user must make a specific set of choices
  2. The user must press modifier keys, such as Select

The following sections contain more information about using modes.

Modes as Choices

You can establish a mode to take effect when the user makes a choice. A tool can represent that choice.

Tools are especially useful in drawing or imaging programs. For example, when a user chooses an eraser tool (activating eraser mode), presses the SELECT button, and moves the pointer within the drawing area, the area of the drawing over which the pointer passes is erased.

The following design principles address mode choice:

  1. Choose a clearly understood text or graphic label for the mode choice and provide appropriate help.
  2. Provide an appropriate visual (or audible) cue to help the user determine the current mode.

    Usually, applications change the pointer or cursor within the control to indicate the current mode. Consider the following when designing visual cues:

    1. Change the pointer to reflect the tool that the user has chosen. For example, when the user chooses an eraser tool, change the pointer to include an eraser graphic.

    2. In text controls, provide an I-beam cursor when the control is in insert mode and a block cursor in replace mode.

    3. In list boxes, provide a box element cursor in normal mode and a dashed element cursor in add mode.

    Remember that users may be unaware of the mode they are in unless there is a clear visual cue. Without such a cue, users may be upset when an action leads to an unintended result or no result at all.

  3. Make sure that the interface indicates to the user how to exit from a mode and that it does so consistently.

    Note that users can exit from a mode in two ways: automatically after completing some action or by picking another mode. For example, in a drawing program, the user may choose rectangle mode to draw a rectangle. If the application exits from the rectangle mode automatically, the user must choose the rectangle mode again to draw another rectangle. If the application does not exit automatically, the user can draw another rectangle immediately or choose another mode.

    Whether to have your application exit from modes automatically depends on the function of the application. Consider basing your decision on a thorough task analysis. In many cases, users appreciate the opportunity to configure the exit mode themselves. Whatever your decision, design all of the tools in a toolbox to exit in the same manner.

    When the application does not exit from a tool mode automatically, design the first tool in a toolbox to display a pointer graphic and establish a standard selection-based mode (that is, one in which the SELECT button is used for selection). For example, in a drawing program, the standard mode could be used to select part of a drawing.

  4. Keep the scope of the mode narrow and allow the user to interact with other parts of the application while the mode is in effect.

    For example, when the user chooses an eraser tool within the drawing area of a drawing program, interactions with the remainder of the interface should behave as usual.

  5. In most situations, do not define a mode that automatically executes an action on selected elements.

    For example, do not define a delete mode that automatically deletes every file the user chooses from a list until the user exits from the mode. Instead, avoid using a mode entirely by allowing the user to first select the files from the list and then choose a delete action.

  6. Do not use a mode when you can use standard techniques.

    For example, do not design a text control that assigns standard printing characters to navigation and editing functions while in an edit mode, such as D for deleting the next character or B for moving the cursor back one character. Instead, use standard nonprinting characters, such as < to go back one character or Delete to delete the next character; or, use a modifier key with a character key such as Ctrl B to go back a character.

Modes with Modifier Keys

Within a control, pressing a modifier key can have different effects. For example, in a scope of selection that uses an extended selection policy, augmentation with Ctrl switches the scope from select mode to toggle mode. That is, ordinarily, pressing the SELECT button and then moving the pointer selects a group of elements, deselecting the remaining elements in the scope. If Ctrl is held down, however, the selection state of the elements is toggled, and the remaining elements in the scope are unaffected.

The following design principles address using augmentation with modifier keys to define a mode:

  1. Design the augmented mode to be a clear variant of the unaugmented mode.

  2. When appropriate, use augmentation that is consistent with its use in standard Motif controls.

    For example, when using the keyboard for navigating or for changing values, the user can press Ctrl to increase the appropriate increment, such as changing the scrolling increment from a paragraph to a page.

  3. Use augmentation with tools only if you can augment a number of tools similarly.

    For example, in a drawing program, once the user chooses a tool, provide a modifier key that determines whether to fill a drawn shape or to switch colors. Users often find it easier, however, to have additional tools rather than to use augmentation with tools.

  4. Be cautious about simultaneously supporting multiple augmentations, that is, allowing different combinations of modifiers to have different effects.

  5. Use visual cues to indicate the current mode.

    Providing a visual cue with modifier keys is not as important as when users choose a mode because users usually remember when they are pressing modifier keys. However, if combinations of modifier keys have different effects, a visual cue might help convey this information.

Making Actions Reversible

The results of a user's actions should be reversible. The following design principles address reversible actions:

  1. Let users learn by exploring: let them try actions to see results and undo actions if the results are not what they expected.

    For example, if a user merges two lists, then decides that the merged list is not appropriate, the user should be able to choose Undo (or press Undo) to return the two lists to their original format.

  2. Design your application so that the user can redo any action that has been undone.

    An action should not cause irreversible consequences. Thus, continuing the previous example, if the user that just undid the work done to the lists needed the merged and sorted lists after all, choosing Redo to restore the previous work is preferable to re-creating the work.

  3. Inform the user if an action cannot be reversed and give the user an opportunity to choose some other action.

    Your application might display a message describing the outcome of a particular action and indicating alternative actions. For example, if the user attempts to erase a diskette, your application should display a message that tells the user that if the action continues, the user will not be able to retrieve the information on the diskette. Always inform the user before the action takes place, not after. The message should also indicate alternative actions that the user can take, such as stopping the action or replacing the diskette in question with another diskette.

  4. Provide as many reversible actions as possible.

    Determine which actions can or cannot be undone. For example, consider which interface actions users might need to undo and provide them as reversible actions whenever possible. Also, provide support to undo as many actions in a series of actions as possible.

For more information on making actions reversible, see the Undo, Redo, Repeat (Action Choices) reference page.

Providing Immediate Feedback

Immediate feedback lets the user assess whether an action has resulted in the desired response. Feedback elements include in-progress messages, information messages, status area, and pointer shape. The following design principles address feedback:

  1. Make the results of the user's actions immediately obvious. If the results are not as expected, the user should be able to choose an alternative action at once.

    For example, when a user is using a group selection technique such as area technique, show selected emphasis on each element as it becomes included in the selection area. Do not make the user wait until the entire selection operation has completed to see whether the intended elements were included.

  2. If the results of the user's actions cannot be made obvious immediately (for example, if a network delay interferes), provide the user with this information.

    If the user's action cannot be processed immediately, let the user continue to interact with the application, if possible. If the user's action must be processed before the user can continue within the application, provide feedback and let the user continue to interact with other parts of the interface.

For information on feedback elements, see the In-Progress Message, Information Message, Pointer (Predefined), and Status Area (Area) reference pages.

Keeping Interfaces Flexible

If an interface is complicated, users become confused. Flexibility within an interface can accommodate different levels of experience, different styles of interaction, and different user needs. The following design principles address interface flexibility:

  1. Provide different ways for users to access application functions and accomplish their tasks.

    For example, provide access to a function through a pull-down menu, direct manipulation of an element, a mnemonic key press, or a shortcut key. However, keep in mind that too much variety can cause confusion.

  2. Design your application so users can configure the interface.

    For example, allow users to reformat the interface by moving elements such as push buttons and menu items, defining macros, and changing input device bindings.

    Letting users change settings and select personal preferences enhances their sense of control and encourages them to take an active role in understanding an application's functions.

  3. Provide a way for users to proceed at a comfortable pace, learning as much as necessary to accomplish the task at hand.

    For example, allow the user to access related help topics on text modes while working in a text-entry field.

  4. Provide a way for users to go beyond the basic level of knowledge required for frequently used features.

    For example, let the user expand windows by choosing the More choice for additional choices and elements.

  5. Design the application to encourage exploration so that, as a user's expertise increases, the user is able to discover and use the application's more advanced features.

    For example, the application might initially display simplified menus that contain only those choices that a novice or casual user would use. As the user becomes more experienced, provide a mechanism for allowing the user to display complete menus of all the application's choices.

  6. Rely on visual cues and avoid making users type extensively or remember details.

  7. Provide hidden mechanisms, such as shortcut keys and condensed sequences of steps. Be sure that they are easy to discover and learn.

  8. Provide ways to remove some visual cues.

    For example, an experienced user should be able to turn off the display of certain kinds of information that are not required.

  9. Ensure that the interface serves the needs of its primary users first, but design it to be flexible enough to accommodate a range of users.

For additional information about designing for users with disabilities, see "Designing for Accessibility".

[ Previous | Next | Contents | Glossary | Home | Search ]