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 Java 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 its components.
  • 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 margin.
  • 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.
• Labels
  • 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 components.
  • 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 associated components.
• 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 of "Apply".
  • Include a "Close" button in a dialog box with an "Apply" (or other action) button. Close dismisses the dialog box without applying changes.
  • 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" button.
  • 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 a default.
• 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 alert box.
  • If appropriate, provide a Help button in an Error alert box to open a separate window that gives background information about the error.

Selection Components

• General
  • 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

• Labels
  • 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).
• Submenus
  • 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.
• Separators
  • 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 the application.
    • 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 Format menu.
• 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.
• Toolbars
  • Include commonly used menu items as buttons (or other components) in your toolbar.
  • Even if your window has a toolbar, make all toolbar commands accessible from menus.
  • 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 identifiers.
  • If your application does not have menus, attach tool tips to the toolbar buttons in order to display keyboard shortcuts.