Class Schedule

Application Development - Design Guidelines (LIS 558 - Lecture 9)

Unfortunately, I do not have a reference for the following because they were given to me by someone who did not have the source information.

In addition to the following tips, the following site (as of March 9, 2000) is an excellent source of Graphical User Interface (GUI) design: http://axp16.iie.org.mx/Monitor/v01n03/ar_ihc2.htm

• only main program windows have title bar icons, menu bars, toolbars, and status bars
• secondary windows must not appear on the taskbar - clicking on a primary window taskbar button activates any secondary windows
• secondary windows should not have the complexity to warrant a menu bar, toolbar, or status bar
• title bar icons are used as a visual distinction between primary windows and secondary windows
• do not use the Windows icon (the flying window icon)
• make the default configuration very simple
• applications should be maximized by default (but depends on convention)
• use Exit command to quit a program; use Cancel to remove modal dialog boxes
• use Close to remove primary windows and modeless dialog boxes
• Use the same term to describe the same thing
• Using different terms for items that have only subtle differences will confuse the user
• Structure of the form should make it easy to perform appropriate action and difficult to perform erroneous actions.
• Use drop-down lists
• Defaults
• save and restore user selections
• program should restore itself to state it was in when last quit
• dialog boxes should generally use last input values for defaults
• provide appropriate defaults
• Never use Irreversible or destructive actions
• Never use a value that would surprise user

• should display correctly in all video modes or should be designed for lowest resolution (e.g., 640x480)
• make modal dialog boxes modal
• never use scrollable dialog boxes
• never use menu bars in dialog boxes used as secondary windows
• between similar dialog boxes use control locations to emphasize similarity
• if same control with same meaning appears in several similar dialog boxes it should appear in the same location (avoid placing different controls that could be confused in the same location)
• set input focus strategically
• use bold text sparingly or avoid it altogether
• provide context-sensitive help
• assign access keys to all controls that can handle access keys
• OK button doesn’t have access key since it is selected with the Enter key when it is the default button
• Cancel button doesn’t have an access key since Esc key is used to dismiss a modal dialog box
• if possible, avoid assigning an access key to a lowercase g, j, p, q, or y, or to a character immediately preceding or following one of these characters (underline doesn’t look right against the character’s descender)
• access keys must be unique

• separate main command buttons from main body of dialog box
• main command buttons include OK, Cancel, Close, Help, Stop, Hide, and other related buttons
• separation makes the main command buttons easier to find and identify
• avoid multiple rows or columns of main command buttons (multiple rows preferred to multiple columns)
• for modal dialog boxes always provide OK and Cancel buttons
• for modeless dialog boxes (or dialog boxes used as primary windows) provide Close button but do not provide OK and Cancel buttons
• always put OK button first, Cancel second, Help last
• OK or its equivalent should always be the first main command button
• Cancel should be to the right of or below OK
• if no OK button place Cancel button just before the Help button
• label OK and Cancel buttons correctly
• OK button should be labeled OK not Ok or OK
• Cancel button should be labeled Cancel not Cancel or CANCEL
• make sure Cancel button really cancels
• when cancelled the program state should be exactly the same as it was before the modal dialog box was displayed
• If not, Cancel button should be replaced with a Stop button
• disable invalid command buttons instead of giving error messages
• never assign a behavior to a double click
• users do not expect command buttons to respond to double clicks so they are unlikely to discover this behavior

• always use single words for menu titles
• keep menus stable
• disable, don’t remove, invalid menu items
• order menu items strategically
• group related items
• more important commands should appear at top of menu, less important commands at bottom
• disable invalid commands instead of giving error messages
• assign access keys
• use the standard menus
• never use "Bang" menus
• items that look like drop-down menus but are commands that execute immediately upon selection, such as Exit

• avoid unnecessary abbreviations
• avoid complex punctuation
• use simple punctuation such as periods, commas, question marks, and dashes but avoid semicolons, exclamation points, parentheses, brackets, etc.
• use consistent capitalization
• avoid distracting backgrounds
• solid, neutral-colored backgrounds
• create good contrast between the text and the background
• Avoid offensive or violent language
• terms such as fatal, execute, kill, terminate, and abort

• avoid error numbers
• use plain English in the error message
• avoid blaming the user
• avoid using words you or your in the error message text
• use passive voice when referring to user actions
• better to say the equivalent of "mistakes were made" than the equivalent of "you screwed up"
• do not use hostile language
• avoid using the terms bad, caution, error, fatal, illegal, invalid, and warning in error message text
• use more specific, descriptive terms instead
• try to explain what exactly is wrong
• don’t try to be funny or clever in the error message text

Group boxes should organize a set of controls on a window. We often see group boxes used as field labels which create visual clutter. Also, group boxes don’t have mnemonics (keyboard shortcuts) since a group box control can never have focus. Instead mnemonics should be associated with fields contained in the group box.

• Most property sheets contain an icon in the upper left of the default tab which identifies the object you are viewing. We try to avoid placing an icon on each tab of the property sheet. Otherwise when you encounter complex tabs in a property sheet you will find yourself redesigning just to fit the data and the icon on each one.

• Bold or non-bold labels?
  If you are following the ‘softer and gentler’ look of Windows-95 and Windows NT you will notice a shift away from bold labels and toward non-bold labels. This approach combined with gray backgrounds has caused problems for many users. We layout our windows with bold labels to ensure enough white-space between the label and the enterable field. Then we provide a user option for setting the labels to bold/unbold.

• Speaking of tips…keep your tool tips brief!
  Tool tips should simply ‘jog’ the memory of the user as to the function of the control. More detailed help can be displayed on the application message bar.

• Don’t abuse ellipsis…
  The ‘…’ symbol is widely abused and misunderstood symbol. Its specific meaning is "More parameters are required to complete the action", not "Another window opens if you click this button!"
• Include those ‘small’ icons!
  Windows 95 will shrink your 32x32 icon automatically to display in the window title bar and in the explorer. However, the automatic laser-guided shrinking algorithm often seems to result in a ‘squished’ unrecognizable mess. To solve this problem create and register 16x16 icons along with your 32x32 icons for all primary windows.
• Don’t confuse mnemonics with accelerators!
  Mnemonics are invoked with an "Alt" key and are useful on menu bar items. Accelerators span multiple drop-down menus and are invoked with the "Ctrl" key modifier. Accelerators are displayed after menu items and mnemonics are displayed on the menu items.
• Include mnemonics on all your window controls for keyboard oriented applications!
  Your users will appreciate not having to constantly move their hands between the keyboard and the mouse to invoke commands. Not doing this can torpedo your user’s productivity!
• Don’t confuse read-only text with static text!
  Information which is either temporarily unavailable or displayed as read-only for users to select, read or copy should be displayed in a normal text box control with an inset border. The color should be the same as the window’s background. Static text is used for field labels and descriptive information in a window. This type of text should appear on a window without a border.

Back to Class Schedule