The primary goal of the interface developer is to create a design that is easy to use and consistent across applications. A user who learns one application with a Motif interface should be able to learn to use other such applications quickly. The interface should also:
Increase productivity
Increase user satisfaction
Reduce user errors
This chapter discusses Motif user interface design principles, which are based on principles of human behavior, the experience of users and researchers, and the results of usability testing.
Occasionally you must choose among design principles. Factors outside your control may lead you to favor one principle over another. For example, cost, performance, and usability concerns sometimes conflict. You must balance these concerns according to their effect on the user and the user's tasks.
The following sections discuss the categories of general design principles:
Placing the user in control of the interface
Reducing the user's memory load
Promoting consistency
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:
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.
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.
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.
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:
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.
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.
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:
The user must make a specific set of choices
The user must press modifier keys, such as Select
The following sections contain more information about using modes.
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:
Choose a clearly understood text or graphic label for the mode choice and provide appropriate help.
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:
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.
In text controls, provide an I-beam cursor when the control is in insert mode and a block cursor in replace mode.
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.
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.
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.
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.
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 Left Arrow 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.
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:
Design the augmented mode to be a clear variant of the unaugmented mode.
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.
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.
Be cautious about simultaneously supporting multiple augmentations, that is, allowing different combinations of modifiers to have different effects.
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.
The results of a user's actions should be reversible. The following design principles address reversible actions:
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.
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.
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.
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.
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:
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.
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.
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:
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.
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.
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.
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.
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.
Rely on visual cues and avoid making users type extensively or remember details.
Provide hidden mechanisms, such as shortcut keys and condensed sequences of steps. Be sure that they are easy to discover and learn.
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.
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 Chapter 12, “Designing for Accessibility”.
The following sections provide information about how to design an interface that does not tax the user's memory.
The user should never have to rely on memory for something an application can ‘remember.’ The following design principles address recognition:
Present alternatives and let a user choose from among them.
People are better at recognition than at recall, so provide visual alternatives. For example, provide lists of items, such as choices in a menu. The user can recognize choices in a menu without having to recall commands or their syntax.
Provide reminders to help a user keep track of the task at hand.
For example, provide visual cues, such as emphasis, gauges, or textual cues. Emphasis reminds users that they are interacting with an element. Gauges remind users that a process is under way. Textual cues tell users what to remember.
When interface elements resemble their real-world counterparts, users transfer knowledge gained in other areas to the computer environment and learn to use applications more quickly. For example, in the real world files are stored in folders and new mail is put into a mailbox; therefore, design your interface elements to resemble their real-world counterparts.
To ensure that metaphors are correctly interpreted, remember that they are evaluated by individual users. For example, an application designed for children should have metaphors that a child can relate to.
When an element represents an abstract notion that does not have a real-world counterpart, provide a representation of the element that helps the user visualize and remember relationships.
Design the interface so that the most necessary and commonly used functions are prominently featured and readily accessible. Consider hiding more sophisticated or less frequently used functions from immediate view. For example, a user should be able to find help immediately upon looking at a window, but you can place the choices for changing the presentation of data in a cascaded menu under the View menu.
Using good visual design principles ensures clear visual communication and improved ergonomics. Well-designed interfaces reduce clutter and prioritize visual elements. For more information about the visual presentation of the interface, see Chapter 9, “Visual Presentation Principles”.
Consistency helps a user transfer knowledge from one application to another. The following design principles address consistent user interfaces:
Develop paradigms that provide for identical implementation of common functions throughout, and across, applications.
For example, the Motif guidelines specify that a user should be able to use the same technique for editing text, regardless of where the text appears.
Ensure that controls are consistent.
Determine whether making one control consistent within an interface will affect the consistency of other controls. For example, user interface controls might be consistent in shape, location, or color, while others might be consistent in interaction techniques.
Remember that consistency is a means to an end — ease of learning, ease of use, and reduction of errors — rather than an end itself. Sometimes it is impractical or impossible to be completely consistent. In that case, make consistency compromises based on your knowledge of the user.
Users can become confused if the interface changes constantly while they work. The following design principles address continuity:
Provide cues that help the user relate an effect to its cause.
For example, displaying the cannot pointer over a target element when the user attempts to drop a source element on it indicates a problem with the target element.
Design your application to maintain useful points of reference while the user works on a task.
For example, when the user adds objects to a container, the appearance of the container's window should remain the same while the appearance of the window's contents changes.
Allow the user to complete a step or a series of related steps without having to alternate between input devices.
For example, the user should not have to use a pointing device to scroll text while editing that text from the keyboard. The text should scroll automatically when the cursor reaches a boundary; the keyboard should have its own scrolling mechanisms, such as keys that move the cursor up or down in the window.
A new application or a new version of an existing application should build on the user's knowledge. Do not discount the user's experiences with other user interfaces, such as those provided in prior versions of an application or those generally accepted as industry standards. When designing your application, design the application to behave in a manner similar to previous versions or to other applications if it is part of a suite of applications. In addition, maintain visual consistency throughout your application and any related applications.
Provide consistent behavior within your application and between applications. Observe the following design principles:
Be cautious about changing the behavior of an application or control from one version of an application to the next.
Test a new behavior to make sure that the benefits outweigh the drawbacks of forcing a user to relearn the behavior of an application or control.
Consider allowing users to choose either old or new behavior for an application or control.
If an old behavior is recognized by many users, consider supporting the old behavior. Although backward compatibility is desirable, a poorly implemented application could result in a mixed model that is not easily learned and used.
Determine whether to continue providing consistency in an existing poor design.
Though consistency is important, it may not be appropriate to continue using a poorly designed interface. Weigh the needs of experienced users against the need for updated design.
Maintain visual consistency throughout your application and between applications, if possible. Pay attention to visual elements such as the typeface and color. Observe the following design principles:
Choose an appropriate font and show differences in levels of information by using different typefaces within that font.
For example, when using the Times Roman font, show differences by making the typeface bold, italic, a different size, or underlined. You can use an additional font when there is a genuine need for more contrast in the information. However, vary the fonts only when the information is significantly different or when the choices of typefaces within an available font are limited.
Design all of one type of element to have the same font and typeface. Pay particular attention to labels, choices, and text fields. For example, design all labels to use one font and typeface.
When choosing a set of fonts to be displayed together, choose fonts that have noticeable contrast. The contrast can be of structure (serif or sans serif), weight, form, size, or any combination of these. Do not choose two serif fonts that are similar in size and weight to indicate different information.
Limit the number of fonts used in an interface to two. Choosing three fonts that work well together is difficult.
Provide clear visual communication.
The user should be able to clearly distinguish one unrelated element from another. For example, if two unrelated elements appear visually similar (such as both are the same color), the similar color might lead the user to believe that a relationship exists between the elements, even though it does not.