Graphical User Interface Standards

Graphical User Interface Standards
1. Fonts

With graphical user interfaces you have more choices in how to display text. This section summarizes good font decisions.

1.1 Use a sans serif font
Use a sans serif font for text and labels. Sans serif is easier to read on screen. Times New Roman is an example of a serif font. It has "feet" on the letters. Arial is an example of a sans serif font. It does not have "feet" on the letters.

1.2 Do not use italics or underlining
Italics and underlining can make text hard to read on a screen.

1.3 Avoid using colored fonts
The easiest type to read is black type on a white or gray background. If you mix colors of fonts on one screen, the colored text will be harder to read than the black text. If you do use a colored font for a special purpose, consider bolding it to make it easier to read. A red font can be used to identify required fields.

1.4 Use bold for emphasis
Use bolding to emphasize certain body text. Do not use color for emphasis because users typically assume color is a cue for text with a different or specific purpose, such as a label or a hypertext link.

1.5 Avoid changing font size
Avoid using font size to get attention. Many different font sizes on one screen can be distracting.

1.6 Use at least an eight-point font
Many people have a hard time seeing fonts less than eight-points. An eight-point sans serif font is the minimum for screen legibility, assuming a seated user at normal viewing distance.

1.7 Minimize the number of different fonts
Limit the number of font types. Try to use one font type for the whole text.

1. Color Choices and Combinations

You now have the capability of using color in your interfaces. Often, however, color decisions distract users rather than enhancing usability.

Use color to get attention
Putting something in a different color on a screen is attention getting. Use color when it is critical that users notice a certain part of the screen.

Use color purposefully
Color is a powerful attention-getting technique. Use it sparingly or it loses its effectiveness. Do not use it only for aesthetic purposes. Every time you use color it should be for a specific attention-getting reason.

Combine color with redundant highlighting
You cannot rely on users recognizing a particular color—for instance, some people have impaired color perception or can change their color palettes. Therefore, you should always combine color with redundant highlighting. For example, make a part of the screen blue and boxed.

Be aware of color blindness
Nine percent of men and two percent of women have some form of color blindness or color confusion. Do not rely on color alone to provide critical cues.

Watch out for color customizing
People can often change their color palettes. Do not refer to parts of the screen by specific color, for instance, "Enter data that is required into the green box." You cannot be sure that the box will always be green.

Use colors consistently
Decide on the specific meanings of colors within an application and use them and their redundant highlighting consistently.

Use color in toolbars sparingly
Because of their typically small size, using color in toolbar graphics is often more of a distraction than it is useful. Use color in toolbar graphics only to distinguish certain aspects of the graphic (different bars on a bar chart icon) or to establish a particular meaning (red in a stop sign).

Follow cultural color meanings
Be aware of the cultural meanings of colors for your particular users. In the United States, for example, some colors have particular meanings.

Color Meaning
Red: Danger, stop, hot, or financial loss
Yellow: Warning or caution
Green: Go or OK
Blue: Cool
Black: Financial profit

Do not violate these meanings and make sure you follow any additional meanings your users have. Be aware of international color associations—they vary from culture to culture.

Use light backgrounds for main areas
The best colors to use for screen and window backgrounds are off-whites and light grays. If you need to use a color other than these, use a pale yellow or pale blue.

Avoid red and blue combinations
Red and blue together, either as background/foreground or in adjacent areas, is very hard on the eyes. The combination of red and blue should be avoided.

Avoid blue text
Recent research shows that saturated blue text is hard to read. Use black text on a light screen.

Use enough contrast
Choose colors for your background and foreground that have enough contrast between them. For example, do not use a light blue background with medium blue text.

Avoid light text on dark
Avoid using light-colored text on a dark background. This combination appears to blue. It is better to use light-colored backgrounds with dark foregrounds. For example, use a light gray background with black text.

Use grayware first
Design in grayware first, adding color as needed. Use light colors for backgrounds and black for text. Although developers often consider this boring, it is best for users over the long run. Save color for when you really need to get someone’s attention. Different shades of gray can be very effective in delineating areas on a screen.

Let users customize color
It is OK to let users customize the colors of an application, but do not use this as a reason for not choosing good color combinations. Users should not have to customize their screen appearance just because you picked poor colors.

Use color palettes
Provide a few color palette choices for users. This enables them to change all the colors quickly, and ensures that general principles for color use are not violated.

Provide a reset
If you let users customize colors make sure you have an obvious and easy way for them to return to the original (default) colors.

Consider showing results before setting
In some cases it may be beneficial to show users the results of their color decisions before they apply them. You can do this by providing a preview function with which they can see the color changes on a small sample screen before finishing the color dialog.
3. Screen Layout
Screen layout principles have been with us for many years. Instead of becoming outdated, however, they have become even more important as more and more visual elements are added to screens. Make sure you follow the basics of good screen layout in your design. Users may decide that an entire application is unfriendly if the major screens are cluttered and hard to follow.

Standard Screen Size
All screens should be developed keeping in mind the target hardware. Typically, today, this should be a minimum of 800 pixels by 600 pixels (800x600).

Form Name Convention
Each form should have a unique name displayed on the top row of the form and should be descriptive in nature. The display of additional titles and/or names elsewhere on the form is redundant and should not occur.

Label all text boxes
Assign a descriptive label to every text box. Avoid acronyms or abbreviations unless you are sure all users will understand them. It is okay to use multiple-word text box labels; however, keep them concise. Capitalize the first letter of the initial word of a label.

Place labels to the left
Place labels for text boxes to the left of the box. Avoid placing labels on top of text boxes.

Align text box labels to the left
Align text box labels on the left. Do not right-align labels. Right-aligned labels produce a ragged left margin, which is hard to scan.

Place a colon after text box labels
Use a colon after text box labels to distinguish between the label and the data that follows. Allow two spaces between the colon and the text box for the longest label. Do not use colons after group frame names or column headings.

Organize windows and dialogs to match work flow
Which windows you have, how much they do, and the order they are in, should match how the users are doing their work.

Use an appropriate amount of information
Each window or dialog should represent one task or subtask in the user’s workflow. If a task is complicated, use more than one window—one for each subtask.

Find a home base
A home base is the screen or window users come back to again and again while working on a particular task. Decide on a window that will serve as the user’s home base. The home base might be a screen of data, a list, or a form with or without data. Home base is not necessarily the first window they see when they enter the application or a particular task. Users might go through a series of selection and list screens before reaching the home base. If at all possible, do not make home base a blank screen with a menu bar. It should be a screen with meaningful information for the task they are performing, for example, a list of contracts or a blank invoice form, ready to be filled in. Having a home base helps users remember what to do, gives them a concrete and visual anchor point, and helps them to alleviate the feeling of being lost in the interface.

Organize information within a window
Information should be placed in a window or dialog box so that it flows well with the task the users have to perform. The most common or critical information should be at the top left of the window or dialog. The flow of the window should then move from top to bottom or left to right.

Choose a horizontal or vertical flow
Decide whether you will use a horizontal or vertical flow of information for each window or dialog. Not every window or dialog has to have the same flow—decide separately for each window or dialog box. However, do not use a mix of horizontal and vertical flows on one window or dialog box. The most common or critical information appears in the top row. Less common or critical information appears in a second row. Buttons to control the window or dialog box are on the top right. Use white space between rows to show the horizontal flow.

The most common or critical information appears in the left column. Less common or critical information appears in a second column. Buttons to control the window or dialog box are centered on the bottom. Use white space between columns to show the vertical flow.

Group similar data
Group similar data together and use frames and white space to show the groupings. Label the groups.

Minimize different margins
Line up data elements and groups to minimize the number of different margins on the screen.
3. Designing or Choosing Graphics


Is a picture worth a thousand words? Only if it is well designed and well used. Here are some ways to make graphics powerful and effective.

Use graphics for a purpose
Decide how a graphic will be used before designing or choosing the graphic itself. Three common uses are:
1. Application icons. These usually appear on the desktop. Clicking them launches the application.
2. Button images. These are simple pictures that are placed on buttons, usually grouped together on a toolbar. Clicking them starts an action in the application, such as printing.
3. Descriptive graphics. These graphics describe and support the user’s task, for example, a picture of a house in a real estate application.

Use button images as shortcuts
Use graphics on command buttons when you want users to find critical or frequently used objects or actions without searching through menus.

Use graphics when a picture is worth…
Some ideas are best and most quickly portrayed with a picture rather than words, for instance, drawing tools or text justification commands.

Use graphics for international use
If you are designing for international and multilingual audiences, consider using graphics to eliminate the need to translate words. However, there are some guidelines to keep in mind when selecting graphics for international audiences:
1. Make sure the graphics are widely understood. Test them with different groups.
2. Do not use any offensive gestures. For example, a pointing finger is considered offensive in some cultures.
3. Use representations that are universally held. For example, scales to show balancing are not a universal representation.

Watch out for picture size
Often pictures that are easily identifiable when they are large become incomprehensible when they get turned into a smaller than postage stamp size picture on a toolbar.

Use standard graphics
If possible, use standard graphics that have already been tested. Check your platform’s guidelines book and your programming tools for standard graphics.

Consider changing the graphic’s state
Consider having a button image change to represent a new idea. For example, a closed file folder representing a file, which then changes to an open file folder representing an open file.

Be consistent
Once you have chosen or designed a graphic, use it consistently. For example, do not use different representations of a phone in different places in your application.

Avoid words
A well-designed button image should not need a label. If users can’t decipher the pictures, you may need to fix the pictures rather than just adding words. If you do use labels, here are your placement choices:
1. Use tool tips. If possible, have the tool tip appear when the cursor passes over the icon.
2. Use a label underneath the picture.
3. Use a label in micro help (line at the bottom of the screen). Use this only if you cannot use either of the above choices.

Get appropriate help
Consider bringing in a graphic artist experienced in design for computer screens and the type of picture you need to create. People who are used to designing corporate brochures might not have the skill set and experience to create tiny pictures for toolbars.

Test your graphics
Make sure you test the graphics you design or choose. There are two basic ways to test:
1. Give users a particular task and ask them to pick the graphic that they believe performs the task.
2. Give users graphics in context and ask them what actions the graphics represent.
3. Charts and Graphs
Graphical user interfaces allow you to show data visually using charts and graphs.

Use graphs to show relationships
If you need to show relationships among different categories or over time, use graphs rather than tables with specific values. People can grasp trends faster from a graph than from interpreting data in a table.

Use bar graphs for categories
If you have discrete categories and are trying to show the relationship between them, use a bar graph. Bar graphs can also show multiple relationships between categories.

Use special effects carefully
Use 3-D effects only if they help communicate the information. Avoid fancy formats if they don’t help the user understand the data.

Use pie charts for part-to-whole relationships
If you want to show part-to-whole relationships, use a pie chart.

Use line charts for continuous data
If you have continuous data, use a line chart rather than a pie or bar chart. A line chart better shows the cumulative effect.

Choose appropriate scales
Choose an appropriate scale for both the X and Y axes of graphs. If the scale is too expanded, you may be exaggerating the effect. If the scale is too small, you may be underreporting the effect.

Consider displaying specific values
If users need to see a specific value as well as a general trend or relationship, show the exact values on the graph itself.

Use visual coding on graphs
Use color, highlighting, shading, or patterns to distinguish parts of a graph.

Use legends for complicated graphs
If graphs have a lot of data and a lot of visual coding, use a legend.

Label graphs and data
Label the graph with terminology users will understand. Consider the following labels:
1. Graph title
2. Lines, bars, or parts of the pie
3. X axis
4. Y axis

Use primary colors to show differences
Use primary colors like green, blue, and yellow in charts and graphs to make sharp distinctions. For example, use a different color for each bar in a bar chart, or each slice in a pie chart.

Use red cautiously
Avoid using red in a chart or graph unless you mean to imply trouble, danger, stop, or loss.

Use close colors to show transition
Use colors that are close to each other, like medium and light blue, to show a transition, for example, sales increasing step by step from month to month.

Use light backgrounds for tables
Use off-white or light gray as the background for data in a table. Use black text for the foreground. Use color only when you need to highlight a particular cell, row, or column.

Use monochromatic backgrounds for graphs
If colors are used in graphs, use a white, gray, or black background.
3. User Controls

Command Buttons
Command buttons are the primary way that users take action within dialog boxes. Use command buttons to convey to users the major actions of a particular box. Users should be able to glance at a dialog box and know what to do there and what to do next, based on the names and placement of the command buttons.

Use command buttons only for frequent or critical immediate actions
Use command buttons when users are going to take immediate action that is frequent or critical. Command buttons act as reminders of what actions can and should be taken. Limit command buttons to a maximum of six on a window. Command button actions can also appear as menu items. If an action is not frequent and not critical, place it on a drop-down menu.

Label buttons carefully
Make sure the label you use for a command button is clear and concise. Use labels with multiple words when they are needed to clearly convey the meaning of the button. Follow book title capitalization rules—capitalize the first letter of all major words.

Label buttons consistently
Choose specific labels for certain functions and use these labels throughout an application and from one application to another. For example, use List to display a table of choices, rather than sometimes List and sometimes Search.

Use industry standards for labels
Some labels have become standard across graphical user interfaces. Use these standard labels if you are performing the functions.

Label Action Keyboard Equivalent
OK Makes changes and closes the window The Enter key

Cancel Does not make changes and closes the window The Escape key

Close Closes the window when changes can’t be made or canceled C

Reset Resets to defaults, leaves window open R
Apply Makes changes, leaves window open A
Help Opens online help H




Consider replacing the OK button with a specific term

If the OK command button results in a specific function such as printing or deleting, consider using the specific term instead of the generic OK.

Size buttons relative to each other
If the length of text for a series of command buttons in a dialog box is similar, make all the buttons in the dialog box the size of the largest button. If the text length for a series of command buttons in a dialog box varies, use two button sizes—one for shorter text and another for longer text. This allows you the button size you need while avoiding too many different sizes. Do not use more than two different button sizes in a dialog box.

Separate buttons from the rest of the dialog box
Use white space to set off the buttons that pertain to the entire dialog box. Don’t crowd buttons with the rest of the controls in the dialog box.

Group buttons together
If you have more than three buttons, use white space to group buttons together. Group buttons to identify:
1. Buttons with similar functions
2. Buttons to leave the window (OK, Cancel)
3. Destructive actions (Delete)

Place buttons consistently
Use one of these locations for buttons:
1. Top right of the window.
2. Bottom right of the window.
3. Do not place buttons in both bottom and right locations in one window.

Match button position to the use of the window
Choose either a vertical or a horizontal design for a particular window and position the buttons to match the design. A horizontal design should have buttons on the top right. A vertical design should have buttons on the bottom. The grouping and layout of data in the window plays a role in determining which design to use. The length and number of buttons are also factors. If you have long button names or a lot of buttons, you may want to use a horizontal design with top right buttons. Careful consideration should be given to the number of buttons placed on the screen. You can make these decisions on a window-by-window or box-by-box basis. Window flow designs do not need to be the same across all windows or boxes.

Position limited action buttons where needed
If a command button pertains to only one part of the dialog box, place the button where it is needed.
Order buttons consistently
Whenever possible, place buttons in the following order:
1. Affirmative buttons to leave the window (OK)
2. Canceling actions to leave the window (Cancel)
3. Unique buttons for the window

Use ellipses (…) to indicate that input is needed
If more input will be required to complete a button action, use ellipses (…) after the button name.

Gray out unavailable buttons
If a button is disabled, display the text as grayed out. For instance, certain actions might not be available in order to restrict a user’s actions until another step is taken. Graying out implies that there is an action the user can take to make the button available. If in fact there is no action the user can take to change the button’s state (the button will never be usable) do not include the button.

Assign a nondestructive default button
Choose one button on the window as the default. If the user presses the Enter key, that button is invoked. Make the most common or important action on that window the default, for example, Print on a print window. Do not use a destructive button, such as Delete, as a default, even if it is the most common or important action for the window.
Option buttons, also known as radio buttons, replace many data entry actions.

Use option buttons for one choice
Use option buttons when users should pick one mutually exclusive choice from a list of options, for example, choosing a pay period in a personnel application.

Label option buttons descriptively
Pick a clear and descriptive label for each option button. For example, send Course Description rather than Course.

Group options buttons together and label them
Place option buttons together in a group. Use a frame to show the group. Use a descriptive label for the entire group.

Align option buttons vertically
Line up option buttons vertically if you have the space, rather than horizontally to make them easier to scan.

Limit option buttons to six or fewer
Limit option buttons to six or fewer choices. If you have more choices, consider using a single selection list box or drop-down list box instead. List boxes are discussed later in this chapter.

Choose an order
Decide on the best order for the option buttons. Some ordering methods include:
1. By frequency—most frequently used options at the top
2. By task—if there is a usual order in which parts of a task are performed
3. BY logic—if there is a logical order, for instance a list of dates


4. By alphabet—only use alphabetical order if the labels match the way your users think about the items.

Avoid binary option buttons
If users need to make yes/no or on/off choices, use a single check box rather than option Buttons. However, use two option buttons for distinct, mutually exclusive choices, such as Male/female.


3. Check Boxes
Check boxes replace some data entry actions and provide a quick way to make multiple choices.

Use check boxes for choosing more than one option
Use check boxes when users can choose one or more options.

Use check boxes for toggling
Use check boxes when users are toggling a feature on or off. It is okay to have just one check box.

Label check boxes descriptively
Pick a clear descriptive label that users will understand for each check box. For example, use Reverse Print Order, not reverse.

Group and label check boxes
Place check boxes together in a group. Use a frame to show the group. Use a descriptive label for the entire group.

Align check boxes vertically
Line up check vertically, if you have the space, rather than horizontally to make them easier to scan.

Limit check boxes to ten or fewer
Limit check boxes to ten or fewer choices. If you have more choices consider using a multiple select list box instead.

Choose an order
Decide on the best order for check boxes. Some ordering methods are:
1. By frequency—most frequently used options at the top
2. By task—if there is a usual order in which parts of a task are performed
3. By logic—if there is a logical order, for instance a list of dates
4. By alphabet—only use alphabetical order if the labels match the way your users think about the items.

Do not use Select All or Deselect All check boxes
If you anticipate users will want to select all of a set of check boxes, or turn them all off, consider using a multiple selection list box with Select All and Deselect All buttons instead of check boxes.
3. Text Boxes

Text boxes are the main way for users to type in data.

Use a border to indicate data entry
Use a text box with a border to indicate that a user can enter or edit data.

Show display-only data without a box
If data is for display only and cannot be changed or added, do not place a box around it.

Gray out temporarily protected fields
If a particular text box is temporarily protected, gray out the box and label to signify that data cannot be entered or changed at this time. For calculated fields, consider using a boxed text box with a gray background and read only access.

Use box length to signify approximate data length
Size text boxes to indicate the approximate length of the field.. If you have text boxes of similar length, make them the same length unless you need to show the exact size of the field. If the length of the field can vary, use text boxes of the same length to minimize the number of unique margins on the screen

Align text boxes
Left align text boxes on the screen to minimize the number of different margins. If a particular text box has a long label, use a different margin for that text box. Limit the number of unique margins to two.

Group text boxes
If you have text boxes that all pertain to similar information, group them together in a frame and label the entire group.
3. List Boxes

List boxes are an alternative to long option button lists. They are also an alternative to data entry and they ensure data integrity.

Use list boxes for long lists
Use list boxes rather than option buttons when you have a lot of options. When you have more than six option buttons use a single select list box.

Use list boxes for dynamic data
If data is likely to change over time, use a list box rather than option buttons. It is easier to change the choices that appear in a list box.

Show three to eight items at a time
Show at least three, but no more than eight items in a list box at a time. If you have more items use a scroll bar to view the rest of the items. See the guidelines on drop-down list boxes later in this chapter.

Label each list box
Choose a label for the entire list box that describes the items inside the box, for example Available Printers. Place the label on the top of the list, left justified, followed by a colon.

Use filters for large lists
If there are more than 40 items in a list, provide a way for users to filter the list to narrow down the number of options from which they must choose.

Use drop-down list boxes to save space
Drop-down list boxes allow you to save window space. Use a drop-down list box if most users will select the first item. However, list boxes hide all but the first option from the users. Users have to go through an extra step to get to the rest of the list. Do not use a drop-down list box if it is important for users to see all the options all the time.

Use a combination list box to allow users to type in an option
A combination list box lets users type in a choice as well as pick it from the list. Use a combination list box when most users know what they want and prefer just typing it in. A combination list box is also useful when the list is long and users could skip down to a lower point in the list by typing in one or more letters. Do not allow users to add items to a list by using a combination list box.

Multiple Selection List Boxes
Multiple selection list boxes are an alternative to long check box lists. Multiple selection list boxes, however, can be hard for users to use. You may need to compensate for their usability problems by following the guidelines below.



Use a multiple selection list box instead of check boxes
Consider using a multiple selection list box instead of check boxes if you have more than five options or your list is likely to change over time.

Consider instructions for multiple selection list boxes
Many users are not familiar with multiple selection list boxes. They might not know that they can choose more than one option or might not know how to choose more than one option. Consider including a line of instruction or a prompt that tells users that they can choose more than one Instructions are particularly important when one window contains both a single selection list box and a multiple selection list box.

Consider a selection summary box
If you use a scrolling multiple selection list box, consider also displaying a box with a summary of what the user is selecting. This way, the user does not have to continually move up and down the list to see what has already been chosen.

Consider multiple selection checklists
Another way to show what the user is selecting is a multiple selection checklist. This combines a multiple selection list box with check boxes that the user can select.

Consider Select All or Deselect All buttons
If you have a set of options and anticipate that users will either want to select them all or turn them all off, consider using a multiple selection list box with Select All and Deselect All buttons, rather than check boxes.
10. Dialog Boxes

Dialog boxes allow users to complete a set of actions for a particular task.

Use modal dialogs for closure
A user must respond to a modal dialog box before they can perform work in any other box or window. Use modal dialog boxes for form filling and small, discrete tasks.

Use modeless dialogs for continuing work
A modeless dialog box is a dialog that can remain open and active even while users perform work in other windows or dialogs. Use a modeless dialog box for tasks that need to be repeated or monitored over time, for displaying different objects at the same time, or when the user needs to have access to menus or toolbars while the dialog box is open.

Use a master window or dialog box
A set of tab cards should reside on a window or dialog box (a "master") that also contains any buttons that affect the entire set of cards. Table 8.1 shows buttons that are commonly found on a master window.

Place buttons appropriately
If a button action pertains only to a specific tab card, place the button on the specific tab card. If a button action applies to the whole tab set, place the button on the master window.

Be consistent
Tab controls should be consistent within and across applications. If you use a master tab window and include OK, Cancel, and Apply buttons in one instance, you should use the same setup in the next instance.

Choose a horizontal or vertical flow
Decide whether you will use a horizontal or vertical flow of information for each tab card. Not every card in a set has to have the same flow—decide separately for each card.

A horizontal flow starts in the upper left and moves to the right. The most common or critical information appears in the top row. Less common or critical information appears in a second row. Buttons to control the window are on the top right. Use white space between rows to show the horizontal flow.

Vertical flow starts in the upper left and moves down. The most common or critical information appears in the left column. Less common or critical information appears in a second column. Buttons to control the window are centered on the bottom. Use white space between columns to show the vertical flow.

Navigation in Secondary Windows
With the mouse and pen, navigation to a particular field or control involves the user pointing to the field and clicking or tapping it. For button controls, this action also activates that button. For example, for check boxes, it toggles the check box setting and for command buttons, it carries out the command associated with that button.

The keyboard interface for navigation in secondary windows uses the TAB and SHIFT+TAB keys to move between controls, to the next and previous control, respectively. Each control has a property that determines its place in the navigation order. Set this property such that the user can move through the secondary window following the usual conventions for reading: in western countries, left-to-right and top-to-bottom, with the primary control the user interacts with located in the upper left area of the window.

You need not provide TAB key access to every control in the window. When using static text as a label, set the control you associated with it as the appropriate navigational destination, not the static text field itself.

In addition, combination controls such as combo boxes, drop-down combo boxes are considered single controls for navigational purposes. For a group of check boxes, provide tab navigation to each control because their settings are independent of each other.

Optionally, you can also use arrow keys to support keyboard navigation between controls in addition to the tab navigation technique wherever the interface does not require those keys. For example, you can use the up arrow and down arrow keys to navigate between single-line text boxes or within a group of check boxes or command buttons. Always use arrow keys to navigate between option button choices and within list box controls.

OK and Cancel command buttons are typically not assigned access keys if they are the primary transaction keys for a secondary window. In this case, the ENTER and ESC keys, respectively, provide access to these buttons.

Pressing ENTER always navigates to the DEFAULT command button, if one exists, and invokes the action associated with that button. If there is no current DEFAULT command button, then a control can use the ENTER key for its own use. Likewise, pressing ESC always navigates to the CANCEL command button, if one exists, and invokes the action associated with that button.

11. Tables and Grids

Tables and grids allow users to enter or view larger amounts of information at a time.

Use tables for comparisons among data
Display a table if users need to compare two or three pieces of data and you can’t predict ahead of time, which they need.

Use grids for multiple data entry
Use grids to allow users to enter several pieces of data at a time.

Label columns
Choose labels for columns that accurately reflect the data.

Use row labels if necessary
If rows contain different data, label each row.

Left justify labels
Left justify column and row labels. Do not use a colon after the label.

12. Tab Control

The keyboard interface for navigation in secondary windows uses the TAB and SHIFT+TAB keys to move between controls, to the next and previous control, respectively. Each control has a property that determines its place in the navigation order. Set this property such that the user can move through the secondary window following the usual conventions for reading: in western countries, left-to-right and top-to-bottom, with the primary control the user interacts with located in the upper left area of the window. Order controls such that the user can progress through the window in a logical sequence, proceeding through groups of related controls. Command buttons for handling overall window transactions are usually at the end of the order sequence.

You need not provide TAB key access to every control in the window. When using static text as a label, set the control you associated with it as the appropriate navigational destination, not the static text field itself. In addition, combination controls such as combo boxes, drop-down combo boxes, and spin boxes are considered single controls for navigational purposes. Because option buttons typically appear as a group, use the TAB key for moving the input focus to the current set choice in that group, but not between individual options -- use arrow keys for this purpose. For a group of check boxes, provide tab navigation to each control because their settings are independent of each other.

Optionally, you can also use arrow keys to support keyboard navigation between controls in addition to the tab navigation technique wherever the interface does not require those keys. For example, you can use the up arrow and down arrow keys to navigate between single-line text boxes or within a group of check boxes or command buttons. Always use arrow keys to navigate between option button choices and within list box controls.

You can also use access keys to provide navigation to controls within a secondary window. This allows the user to access a control by pressing and holding the ALT key and an alphanumeric key that matches the access key character designated in the label of the control. A group box is a special control you can use to organize a set of controls. A group box is a rectangular frame with an optional label that surrounds a set of controls. Group boxes generally do not directly process any input. However, you provide navigational access to items in the group using the TAB key or by assigning an access key to the group label.
13. Pop-up Menus and Messages


Pop-up menus provide shortcuts for expert users.

Use pop-up menus for specific options
Pop-up menus appear when users click the right mouse button. Use them for a subset of actions specific to the place or action. For example, if a user clicks the right mouse button on text in a word processing application, the pop-up menu would contain actions that could be taken on that text, such as Cut, Copy, Paste, and Formatting.

Use redundant interactions
Don’t make a pop-up menu the only place an action appears. Also provide a menu item, command button, or toolbar button for the action.

Message Boxes
A message box is a secondary window that displays a message or information about a particular situation or condition. Messages are an important part of the interface for any software product. Messages that are too generic or poorly written frustrate users, increase support costs, and ultimately reflect on the quality of the product. Therefore, it is worthwhile to design effective message boxes..

Message Box Types
Message boxes typically include a graphical symbol that indicates what kind of message is being presented.

Most messages can be classified in one of the categories shown below:
Information Provides information about the results of a command. Offers no user choices; the user acknowledges the message by clicking the OK button.

Warning Alerts the user to a condition or situation that requires the user's decision and input before proceeding, such as an impending action with potentially destructive, irreversible consequences. The message can be in the form of a question -- for example, "Save changes to My Report?”

Critical informs the user of a serious problem that requires intervention or correction before work can continue. The system also includes a question mark message symbol. You can include your own graphics or animation in message boxes. However, limit your use of these types of message boxes and avoid defining new graphics to replace the symbols for the existing standard types. Once the user activates the application, the message box can be displayed. Display only one message box for a specific condition. Displaying a sequential set of message boxes tends to confuse users.

Message Box Text
The message text you include in a message box should be clear, concise, and in terms that the user understands. This usually means using no technical jargon or system-oriented information.
In addition, observe the following guidelines for your message text:
• State the problem, its probable cause (if possible), and what the user can do about it – no matter how obvious the solution may seem to be. For example, instead of "Insufficient disk space," use "'Sample Document' could not be saved, because the disk is full. Try saving to another disk or freeing up space on this disk."
• Consider making the solution an option offered in the message. For example, instead of "One or more of your lines are too long. The text can only be a maximum of 60 characters wide," you might say, "One or more of your lines are too long. Text can be a maximum of 60 characters in Portrait mode or 90 wide in Landscape. Switch to Landscape mode now?" Offer Yes and No as the choices.
• Avoid using unnecessary technical terminology and overly complex sentences. For example, "picture" can be understood in context, whereas "picture metafile" is a rather technical concept.
• Avoid phrasing that blames the user or implies user error. For example, use "Cannot find filename" instead of "Filename error." Avoid the word "error" altogether. Make messages as specific as possible.
• Avoid mapping more than two or three conditions to a single message. For example, there may be several reasons why a file cannot be opened; provide a specific message for each condition.
• Avoid relying on default system-supplied messages, such as MS-DOS® extended error messages and Kernel INT 24 messages; instead, supply your own specific messages wherever possible.
• Be brief, but complete. Provide only as much background information as necessary. A good rule of thumb is to limit the message to two or three lines. If further explanation is necessary, provide this through a command button that opens a Help window.
• Informative messages that do not require interaction from the user can be placed in the status bar and a beep issued to alert the user to the message. For example, upon leaving a particular field an automatic update to the database may take place. The user needs to be notified of the situation but need not respond to a message.


14. Primary and Secondary Windows

Windows are the backgrounds that the rest of your interface controls sit on.
Use cascading windows
Cascading windows keep users focused on one task at a time. However, if by cascading you cover up information that needs to be viewed simultaneously, allow for the use of tiling.

Tiling windows allows users to display multiple windows at one time without covering up other windows. However, the more windows the user opens, the more the windows shrink to accommodate the additional windows. Therefore information can also be hidden when using tiling.

Avoid horizontal scrolling
Avoid having users scroll horizontally to see information in a window or dialog box. Instead of horizontal scrolling, try one or more of the following:
1. A larger window
2. Breaking the information up into more than one window or using tabs
3. Allow expanding, zooming in, and collapsing to show only some information at a time

Size secondary windows to fit data
Size secondary windows to best fit the information in them. Do not rely on users to resize windows, even if the window allows it. All secondary windows do not have to be the same size.

Place pop-up windows in the center of the action
Place pop-up windows and dialogs in the center of the area they relate to in the application window.
15. Menus and Menu Bars

Menus play two critical roles in graphical user interfaces. They are a major method of navigation through the interface and they convey the mental model to the user in a snapshot. Giving attention to the design of usable menus is time well spent.

Word menu titles and items carefully
Pick names and test them to ensure that they make sense to users. It is not easy to pick labels that users will understand.

Change menus, as you need
It is okay for menu bars and their drop-down menus to change as users move through an application.

Use initial capitals
Menu bar titles and items should have an initial capital letter with the rest of the word in lower case. For drop-down menu items, follow book title capitalization rules—capitalize the first letter of all major words.

Follow industry standards for menus
Follow industry standards on menu bars and drop-down menus. You do not have to use these menu bar titles or their drop-down menus if you do not have these tasks in your menu, but if you do use them, follow the standards. If appropriate, provide shortcuts (hot keys) for frequent users. Use of hot keys will be consistent within the system. If you have any questions regarding a menu title or the sequence that they should be arranged, you can refer to any of the Microsoft Office products.

Menu items are the individual choices that appear in a menu. Menu items can be text, graphics -- such as icons -- or graphics and text combinations that represent the actions presented in the menu. The format for a menu item provides the user with visual cues about the nature of the effect it represents. Always provide the user with a visual indication about which menu items can be applied. If a menu item is not appropriate or applicable in a particular context, then disable or remove it. Leaving the menu item enabled and presenting a message box when the user selects the menu item is a poor method for providing feedback.

In general, it is better to disable a menu item rather than remove it because this provides more stability in the interface. However, if the context is such that the menu item is no longer or never relevant, remove it. For example, if a menu displays a set of open files and one of those files is closed or deleted, it is appropriate to remove the corresponding menu item.

If all items in a menu are disabled, disable its menu title. If you disable a menu item or its title, it does not prevent the user from browsing or choosing it. If you provide status bar messages, you can display a message indicating that the command is unavailable and an explanation why.

The system provides a standard appearance for displaying disabled menu items. If you are supplying your own visuals for a disabled menu item, follow the visual design guidelines for how to display it with an unavailable appearance.

Menu Bars

Menu bars point to major functionality in the application. Choose, organize, and name menu bar titles carefully.

Match menu bars to the users’ workflow
When users look at a menu bar it should match how they think of their work. Spend time deciding on and testing menu categories to make sure they fit the users’ mental model.

Give critical or frequent tasks even weight
Make sure all critical or frequent tasks are represented equally on the menu bar. Avoid grouping all critical or frequent items under one category, and then using the remaining five or six titles on the menu bar for different, but nonessential tasks.

Place application-specific menu titles where they fit
Place menu bar titles that are specific to your application where they best fit, for example, Jobs and Preferences before Help.

Use only one word for menu bar titles
Titles on the menu bar must be one word only. If they are more than one word, or use hyphens or dashes, it is hard to tell whether they are one item or two.

Use only one line for the menu bar
Menu bars must be only one line long. If you have too many titles on your menu bar for one line, then collapse some of your titles into one.

Do not gray out menu bar titles
Do not use graying out to make menu bar titles temporarily unavailable. Instead you should either not show the item at all or place the item on a drop-down menu where it is appropriate to use graying out.

Menu bar titles should always activate a drop-down menu
Menu bar titles should not initiate actions directly. Items on drop-down menus can initiate actions.

Drop-Down Menus
Drop-down menus reveal more detailed information to the user. Word and order them carefully.

Use more than one drop-down menu item
Drop-down menus should have more than one item on them. If you have a menu bar title that has one or no drop-down items, it should not be a separate menu bar category. Combine it with another menu title.

Use unique drop-down menu items
Do not start each drop-down item with the same word that is on the menu bar. Drop-down items should be unique.

Limit drop-down menus to one screen in length
Drop-down menus can go from the top of the screen to the bottom of the screen. Do not use scrolling. If you have more items than will fit on the screen, you will need to combine some items and use cascading drop-downs, or separate some items into an additional menu bar item.

Put frequent or critical items at the top
Place the most frequent or critical items at the top of the drop-down menu.

Use separator bars
Whenever a menu contains a set of related menu items, you can separate those sets with a grouping line known as a separator. The standard separator is a single line that spans the width of the menu. Avoid using menu items themselves as group separators. Use separator bars in two ways—to group related items and to separate destructive items

Use no more than two levels of cascading
It is okay to use cascading drop-down menus, but do not use more than two levels of cascading. Use the right arrow symbol (>) to the right of the drop-down menu item to denote that the item has a cascading menu.

Use ellipses (…) to denote dialogs
If more input will be required to complete an action, use ellipses (…) after the drop-down item

Use industry standard keyboard equivalents
A keyboard equivalent allows users to choose a menu item without using the mouse. A keyboard equivalent requires that the drop-down menu be open when it is used. All drop-down menu choices should have keyboard equivalents.

Use accelerators sparingly
Accelerators are combinations of keystrokes that allow users to choose a menu item when the drop-down menu is not open, as shown in Figure 8.23. Use accelerators only for those drop-down menu items that you think users will want to use without pulling down a menu, for example, Ctrl+V to paste from the clipboard.

Use consistent accelerators
Use consistent accelerators in your enterprise-wide applications. Place the accelerators in the drop-down menus to the right of the drop-down menu item.
16. Tools Bars

Toolbars serve as a menu shortcut, or as a way to present controls that would be hard to convey in words, like drawing tools.

Make toolbars consistent
If you use a toolbar throughout the application, or between applications, make sure you use the same button graphics for the same functions throughout.

Make only active items available
Only toolbar items that are currently available should display. It is okay for some toolbar items to not show at all and for others to display as users move from one part of the application to another. It is all right for some items on a toolbar to be grayed out if they are only temporarily unavailable.

Allow users to move some toolbars
Allow users to move some toolbars to different locations on the screen to ensure they are out of the way of the work the users are performing.

Allow users to toggle toolbars on and off
Let users turn toolbars on and off through a dialog box or an option on a drop-down menu. This is
Especially important if you are providing more than one toolbar.

Allow customizing
Consider allowing users to customize their toolbars by deciding what to put on or take off the toolbar. You should, however, make decisions on what should be on the toolbar and provide that as the default. Most of the time, users should not have to customize a toolbar for it to be usable.

Use buttons with a purpose
Pay attention to the number of buttons on a toolbar. Too many buttons create visual and cognitive strain. Users will not see some of the buttons if there are too many.

Group like items
If you have a lot of buttons on a toolbar, consider grouping them. For example, place all editing graphics together. Use white space to group them.
17. Relationship between Tools Bars, Command Buttons, and Menus

You will need to decide which actions go in the menu system, which go on the toolbar, and/or which actions should be buttons on a window.

Use toolbars for frequent actions across screens
Toolbars should contain actions that users need to take frequently and need to access across several screens. Do not use toolbars instead of command buttons.

Action Type Proper Placement
Most frequent and critical Command buttons
Fairly frequent and across several screens. Toolbars

All actions: frequent, critical, and infrequent Menu bar and drop-down menus

Use toolbars to supplement menus
Some toolbar items are used in conjunction with menu bars when users need a shortcut for certain actions. In these cases the toolbar items also appear on the menu bar.

Use toolbars in place of some menu items
Some toolbar items can be used in place of menu items. For instance, some drawing tools cannot be described with words and would be difficult to place on a drop-down menu.