The Windows Interface
A Summary of GUI Guidelines

To conform to the object-action paradigm, applications must provide users a means of selecting objects. Highlighting is the visual feedback indicating that an object or data has been selected. Selected text in windows and in dialog boxes should be highlighted in the same way. In general, selection highlighting should be visible only when the window is active. In special cases, the selection highlighting may be visible in an inactive window, e.g., when the user chooses a command with a dialog box that affects the selection.

Please see the Microsoft Design Guide for discussion of highlighting graphics.

There are two types of selection: single (one item) or multiple ( more than one item).

Multiple selections differ on the following two dimensions.

1) If the selected items are next to each other, then the multiple selection is contiguous. If not, the multiple selection is disjointed.

2) If the items have the same attributes, the multiple selection is homogeneous. If the items have one or more different attributes the multiple selection is heterogeneous.

The starting point of a selection is its anchor point. The ending point of a selection is its active end. A selection may be adjusted by changing is size relative to its anchor point. To extend a selection, the user moves the active end of a selection away from the anchor point. From the anchor point, the selection can be extended in either direction, but not in both at the same time. To reduce the selection, the user moves the active end is toward the anchor point. When the active end is moved to the anchor point, the anchor point becomes an insertion point.

To deselect data, a user generally clicks to make a new selection. This default deselection behavior is overridden when a user applies disjoint selection techniques. It is also overridden by the recommended behavior of multiple-selection list boxes (please see section on Dialog Box Controls).

In multiple selections, items can be deselected individually or as a group. The combination ctrl+click is the recommended technique for deselecting a single selected item. This combination should toggle the selection state of the clicked item while preserving the state of all other items.

In general, selection techniques that set special selection modes are not recommended except in a special context. If used, a special selection mode should only supplement standard selection techniques. A visual cue should indicate that the special selection mode is active. An example of a special selection mode is the extend mode which behaves as if the shift key is locked down for all direction keys and mouse actions. The f8 key should be used to toggle extend mode on and off.

(Please see the Microsoft Design Guide for keyboard selection techniques.)

Mouse selections are accomplished with click and drag. In general, click selects a single item or location. In applications that do not use drag for item movement, drag selects the range of items between the button-down and button-up location points. In applications that use drag for item movement, then outline selection (described below) is used to select a range of contiguous items.

Mouse techniques for item selection are as follows. (All clicks are with mouse button 1.)

Note: Please see the Microsoft Design Guide for mouse selection techniques for text-oriented applications; margin selection technique for text and arrays; and outline selection of graphical objects.

Focus is the area of the interface that will receive the next input. For mouse input, focus always coincides with the pointer (button down) location. For keyboard input, focus depends on context. In menu and dialog box controls, an active control indicator identifies the control that will be affected. The active control indicator can be an insertion point, text highlighting, or a dotted box. (Please see the Microsoft Design Guide for a discussion of the use of insertion points, text highlighting, and dotted line to indicate focus.) When an inactive window is reactivated, focus and selection should be in the same locations as when the window was last active.

Navigation allows the user to move focus. Mouse navigation is simple and typically does not affect existing selections. Keyboard navigation is more complicated.

Keyboard navigation to data items relies on several keys (home, end, arrow keys). Keyboard navigation changes the selection unless the scroll lock mode is in effect.

Keyboard navigation to controls relies on the tab, enter, esc keys and key combinations consisting of alt and a mnemonic character in the label of the desired control. A mnemonic key combination moves focus to the control, selects the control, and activates the control. Focus usually remains on the control after the operation. The exception is when focus is on a list box and alt + mnemonic key combination is used to operate another control. In this case, focus should return to the list box. For example, the user selects an item in a list box and then uses alt +d to activate the delete control button. After the item is deleted, focus should return to the list.

Use alt + mnemonic key to navigate among controls in a dialog box. When alt + mnemonic key is used to reach and operate a control, focus usually remains on the control after the operation (unless the operation closes the dialog box). For controls that do not capture character input when they have focus (i.e., controls that are not text box, list box, or combo box) a mnemonic character key can be used without alt.

(Please see the Microsoft Design Guide for discussion of keyboard access to control bars, transferring objects and data from one location to another, and direct manipulation.)

Applications should provide feedback to keep the user informed of the current state of the application. Feedback can acknowledge a command, signal that a mode has been activated, alert the user of an error, or track the progress of an application. The most common feedback is visual (graphics, text, or both). Auditory feedback is also useful.

Graphical feedback techniques include highlighting, focus, pointer changes. (Please see the Microsoft Design Guide for suggested pointer shapes and their uses. Also see the Microsoft Design Guide for discussion of feedback for drag-and-drop operations.)

When an operation that prevents a user from continuing work takes more than two or three seconds but no more than five seconds, the application should display an hourglass pointer over the inaccessible window. If possible, the application should let the user access the system or work in another application. If the user is allowed to access the system or work elsewhere, the pointer should resume normal display when moved to an accessible window.

When an operation takes more than five seconds, the application should display the hourglass pointer and a progress indicator. A progress indicator assures the user that the application is working on the task and indicates how much of the work has been completed.

A progress indicator must be dynamic. Do not use static messages or pictures. The feedback from the progress indicator must be obvious and unambiguous. The best progress indicators are graphical (e.g., rectangular bar that fills from left to right with color or animated cursors). Percentage-complete messages can be used to supplement a graphical indicator or instead of a graphical indicator that takes too long to update.

If the duration of a task is not known in advance, use an elapsed-time message instead of a percentage-complete message. Use an elapsed-time message if one step of a task takes a long time to complete. If a task is very long, consider breaking it down into subtasks and using progress indicators for each subtask.

When possible, progress indicators should include a way of pausing and resuming lengthy operations if the rest of the system will not be adversely affected. The recommended way to provide pause/resume capability is through a command button with a label that toggles between Pause and Resume. If the nature of an operation does not permit pause/resume functionality but does allow an irreversible interruption, the progress indicator should contain a command button labeled Cancel or Stop. The Cancel button interrupts the operation and returns the application and data to its state before the operation was invoked. The Stop button interrupts the operation but does not reverse any changes already caused by the operation. Stop should be used only if the application and data cannot be returned to its state before the operation began.

Flashing for attention signals the user that an active application needs to display a message dialog. If the application is a window, the title bar should flash. If the application is minimized, the icon should flash. The flash should be accompanied by one or two beeps. When the user activates the application, a message dialog is displayed.

Textual feedback should be provided when graphical feedback is not a precise enough form of communication. Textual feedback should be in the form of brief messages in the message bar or status bar at the bottom of the screen or in modal dialog boxes.

1. State the information, problem, or error clearly. Use terminology that is straightforward, easy to understand, and familiar to the user. Avoid technical descriptions or explanations.

2. Limit the message to two or three lines. Status bar messages should not exceed one line.

3. Suggest a solution, if possible.

4. Avoid phrasing that blames the user or implies user error. For example, use "Cannot find SAMPLE.TXT" instead of "File name error." Avoid the word "error" altogether.

5. Use "cannot" instead of "can not" or "can’t."

6. Use the message format "Not enough __________ to __________" instead of messages such as "Disk space is full" or "Insufficient memory." For example, "Not enough space on drive C: to save file SAMPLE.TXT."

7. Do not use colons in messages. For example, use "Cannot read SAMPLE.TXT" instead of "Cannot read: SAMPLE.TXT."

8. If a message is accompanied by a message number, place the number at the end of the message text.

9. Left-align multiple line messages.

The system beep is the most common auditory feedback. Auditory feedback can alert users to minor and obvious errors. Auditory feedback can also be used with other forms of feedback. Use system beeps sparingly. Users (and other people within hearing distance) find beeps annoying. Overuse may lessen the effectiveness of beeps. Remember: users can turn off the warning beep. Also, beeps are ephemeral feedback; they leave no trace. If for some reason the user cannot hear a beep, it will fail to communicate its message.

Users should not be required to click on anything other than an object in order to move it.

Note: Please see the Microsoft Design Guide for discussion of recommended text-editing actions and text frames.