CS 338: Graphical User Interfaces
The following list is a compilation of the design guidelines presented in lecture
that should be followed in the assignments. These guidelines derive from the
Look & Feel Design Guidelines and represent those guidelines which are
most important for this course and for general GUI development.
Windows & Layout
- Layout process
- Include 12 pixels between the top and left borders of a dialog box and
- Place 17 pixels of vertical space between the command button row and
the other components.
- Buttons must have the same width and must right-aligned along the bottom
- When designing a dialog box, place the most important options, or those
you expect users to complete first, prior to others (in reading order).
- Align related components vertically using a chosen design grid column,
and horizontally using a chosen design grid row.
- Place labels before the component to which they refer (generally, above
and to the left).
- Align labels with the tops of their components.
- Insert 12 pixels between the trailing edge of a label and any associated
- Left-align all vertically aligned labels.
- Insert 12 pixels after the edge of the longest label.
- Command buttons
- Center all button text, with a 12-pixel left & right boundary between
button label and button edge.
- Make all grouped command buttons equal width, which doesn't change when
window is resized.
- Space buttons in a group 6 pixels apart.
- Make the default button the left-most button.
- Insert 17 pixels between these & rest of window.
- Radio & check-box buttons
- Align the leading edge with that of other components.
- Space grouped buttons 6 pixels apart.
- Space separate groups 12 pixels apart.
- Toolbar buttons
- Space individual toolbar buttons 2 pixels apart.
- Space groups of toolbar buttons 11 pixels apart.
- Include 3 pixels of space above and below all toolbar buttons.
- Interface text
- Most components use "headline" capitalization.
- Alerts, errors, and long labels use "sentence" capitalization.
Dialogs & Alerts
- Dialog boxes
- Use layout managers!
- Specify a logical tab traversal order for the user interface elements
in a dialog box.
- Command buttons
- Place command buttons that apply to the dialog box as a whole in the command
button row at the bottom of the dialog box.
- Align buttons in the command button row along the lower-right edge of
the dialog box.
- Place command buttons that apply to one or a few components next to their
- OK & Cancel
- When users click "OK", save the settings (or carry out the
commands) and close the dialog.
- Whenever possible, provide the button with a command name that describes
the action (such as Print or Find) instead of OK.
- When users click "Cancel", close the window and restore the
settings to the state they were in when the dialog box was opened.
- Apply & Close
- Use "Apply" to carry out the changes users specify in a dialog
box without closing the window.
- Whenever possible, in use a specific action name (such as "Find") instead
- Include a "Close" button in a dialog box with an "Apply"
(or other action) button. Close dismisses the dialog box without applying
- If the user has made changes in a dialog box and clicks Close before
clicking the Apply button, display a Warning alert box to apply changes,
discard changes, or cancel the close operation.
- Close only
- Never use an "OK" button in a window that has a "Close"
- When users click the "Close" button, dismiss the dialog box
and do not make additional changes to the system.
- Default button
- If a dialog box has a default button, make it the first (left-most)
command button in the group.
- Commands that cause the user to lose data should never be the default
button, even if they are the most common option.
- Alert boxes
- Begin your message with a brief heading in bold.Start the body of the
message on a separate line.
- If appropriate, provide a Help button in an alert box that opens an
additional window with more information.
- Info alerts
- Provide a Close button to dismiss an Info alert.
- Warning alerts
- Keep the message in a Warning alert box brief, and use terms that are
familiar to users.
- Include at least two buttons in a Warning alert box: one button to perform
the action and the other to cancel the action.
- If the most common action could result in data loss, do not provide
- Error alerts
- In the message of an Error alert box, explain what happened, the cause
of the problem, and what the user can do about it. Keep the message brief
and use terms that are familiar to users.
- If possible, provide buttons or other controls to resolve the error
noted in the Error alert box.
- Label the buttons according to the action they perform.
- If users cannot resolve the error, provide a Close button.
- If appropriate, include an error number in the title bar of an Error
- If appropriate, provide a Help button in an Error alert box to open
a separate window that gives background information about the error.
- Put your selectable list in a scroll pane.
- Put your selectable table in a scroll pane.
- Put your selectable tree in a scroll pane.
Text & Panels
- Keep label text brief, and use terminology that is familiar to users.
- Use headline capitalization in the label text and place a colon at the
end of the text.
- Use sentence capitalization in the text of a label that communicates
status. (Use a period only when text is a complete sentence.)
- Make a label unavailable when the component it describes is unavailable.
Menus & Toolbars
- Menu bars
- Use menu titles that make it easy for users to determine which menu
contains the items of interest to them.
- Use a single word for each menu title.
- Be sure to include mnemonics for every menu title in your menu bar.
- Do not display menu bars in secondary windows.
- If your application needs the commonly used menus, place the menu titles
in this order: File, Edit, Format, View, and Help.
- If needed, insert other menus between the View and Help menus (and sometimes
between Edit and View, as appropriate).
- Minimize the use of submenus.
- If you want to present a large or complex set of choices, display them
in a dialog box.
- Menu items
- Make your menu items brief — typically verb phrases (e.g.,
“Align Left”) or nouns (e.g., “Font”).
- Never give a menu item the same name as its menu title.
- Use headline capitalization for menu items.
- Include mnemonics for all menu items.
- Offer keyboard shortcuts for frequently used menu items.
- Use the same keyboard shortcut if a menu item appears in multiple menus.
- Use the same mnemonic if a menu item appears in multiple menus.
- If a menu item does not fully specify a command and users need a dialog
box to finish the specification, use an ellipsis (“...”) after
the menu item.
- Do not use an ellipsis mark simply to indicate that a secondary or utility
window will appear.
- Use separators to group similar menu items in a way that helps users
find items and better understand their range of choices.
- Users can never choose a separator.
- While separators serve important functions on menus, avoid using them
elsewhere in your application.
- Checkbox menu items
- Use checkbox menu items with restraint.
- If users must set >2 related attributes, place the checkboxes in
a dialog box (or provide a utility window or toolbar buttons for the attributes).
- Use checkbox menu items instead of toggle menu items (e.g., “Italics
On” and “Italics Off”)to indicate choices you can turn
on or off.
- Toggle menu items confuse users — it is unclear if the
commands are telling users the current state of the selected object,
or the state they can change the object to by choosing the menu item
- Radio button menu items
- To indicate that the radio button items are part of a set, group them
and use separators to separate them from other menu items.
- File menu
- Place commands that apply to the document or the main object (or the
application as a whole) in the File menu.
- If your application manipulates “non-file” objects, give
the File menu a different name.
- When the Close item dismisses the active window, close any dependent
windows at the same time.
- Provide an Exit item, which closes all associated windows and terminates
- Be sure to use Exit, not Quit! (by convention)
- Edit menu
- Place commands that modify the contents of documents or other data in
the Edit menu.
- Format menu
- Place commands that change the format of objects, usually text, in the
- View menu
- Place commands that change the view of the data in the View menu.
- Ensure that commands in the View menu alter only the view/presentation
of the underlying data without changing the data directly.
- Help menu
- Place access to online information about the features of the application
in the Help menu.
- Include “About <app-name>” as the last item and place
a separator before the item.
- “About <app-name>” should display a window with
the product name, version number, company logo, product logo, legal
notices, and names of contributors.
- Contextual menus
- Ensure that all features presented in contextual menus are also available
in more visible and accessible places, such as drop-down menus.
- Display keyboard shortcuts and mnemonics in contextual menus that are
consistent with their usage in any corresponding drop-down menus.
- Include commonly used menu items as buttons (or other components) in
- Even if your window has a toolbar, make all toolbar commands accessible
- Be sure to provide tool tips for all toolbar buttons.
- Because toolbars can be difficult for users with motor impairments and
are not always regarded as a good use of space, provide a way to hide
each toolbar in your application.
- Provide large and small graphics (e.g., 24 x 24 and 16 x 16
pixels) in your application and enable users to select the large graphics
in all parts of the application, including the toolbars.
- Toolbar tool tips
- Ensure that the keyboard shortcuts for toolbar buttons match the keyboard
shortcuts for the corresponding menu items.
- Attach tool tips to all toolbar components that do not include text
- If your application does not have menus, attach tool tips to the toolbar
buttons in order to display keyboard shortcuts.