This page has been relocated to the new instance of the Sahana Wiki. Please reference it here. Thank you.

GUI Standards

Most modern applications have a very similar layout to their main windows. They offer a view of a document and the controls needed to manipulate it. Feedback of what is happening to the document is usually displayed on a status bar.

Several points must be fulfilled before a piece of software may be termed “user friendly” (note that even today, 80 to 90% of software doesn't fulfill every point).

To be user friendly, software must be:

  • task-suitable: - Don't offer so much functionality that it confuses the user or harms functionality.
  • understandable: - When the user uses the application for the first time, the user should be able to see quickly what it does and how to use it.
  • navigable: - The user should always be able to tell where he/she/it is. Don't restrict navigation too much.
  • conformable to expectations: - The application should be consistent throughout!
  • tolerant of mistakes: Users are human: - they make mistakes. The application should allow them to Undo (without crashing, in particular).
  • feedback-rich: - The application should always give immediate feedback to the user regarding which actions(s) are being taken.

Golden Rules of Interface Design

  1. Strive for consistency
    1. consistent sequences of actions should be required in similar situations
    2. identical terminology should be used in prompts, menus, and help screens
    3. consistent color, layout, capitalization, fonts, and so on should be employed throughout.
  2. Enable frequent users to use shortcuts
    1. to increase the pace of interaction use abbreviations, special keys, hidden commands, and macros
  3. Offer informative feedback
    1. for every user action, the system should respond in some way (for example, a button will make a clicking sound or change color when clicked to show the user something has happened)
  4. Design dialogs to yield closure
    1. Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions shows the user their activity has completed successfully
  5. Offer error prevention and simple error handling
    1. design the form so that users cannot make a serious error; for example, prefer menu selection to form fill-in and do not allow alphabetic characters in numeric entry fields
    2. if users make an error, instructions should be written to detect the error and offer simple, constructive, and specific instructions for recovery
    3. segment long forms and send sections separately so that the user is not penalized by having to fill the form again - but make sure you inform the user that multiple sections are coming up
  6. Permit easy reversal of actions
  7. Support internal locus of control
    1. Experienced users want to be in charge. Surprising system actions, tedious sequences of data entries, inability or difficulty in obtaining necessary information, and inability to produce the action desired all build anxiety and dissatisfaction
  8. Reduce short-term memory load
    1. A famous study suggests that humans can store only 7 (plus or minus 2) pieces of information in their short term memory. You can reduce short term memory load by designing screens where options are clearly visible, or using pull-down menus and icons
  9. Prevent Errors
    1. Steps can be taken to design so that errors are less likely to occur, using methods such as organizing screens and menus functionally, designing screens to be distinctive and making it difficult for users to commit irreversible actions. Expect users to make errors, try to anticipate where they will go wrong and design with those actions in mind.

Common Standards:

Required UI Elements

  • Login Screen
    • User ID and Password should be captured
    • Password field should be masked
    • Errors on invalid credentials should be descriptive
    • Field Captions should be same across all the modules
  • Change Password Screen
    • Old, New and Confirm New should be captured
    • All password fields should be masked
  • Use of Auto complete feature
    • Auto completion feature can be set on for frequently used fields
    • It should not be used for fields with sensitive data, such as password input
  • Grammar and Spelling
    • Text appear in GUI pages should be checked for spelling and Grammar
    • MS Word can be used for simple checking
  • Logout
    • There should be a link to logout from current session
    • Session should expire
  • Error messages
    • Error messages should be descriptive
    • Should be consistent
    • Should be short
      • It would be nice if they are configurable
  • Acknowledgments
    • User should be acknowledge on events/changing status (e.g. On Update, Delete, Add etc)
    • Message should be consistent
    • Message should be shorter
  • Consistency
    • Look and feel should be same in all supported browsers
    • Look and feel should be same across all the modules
  • Title Text
    • Title should be appropriate to the current screen
    • Should be short
  • Use of controls
    • Appropriate controls should be used in the HTML pages
  • Length of text inputs
    • Length of fields should be sufficient for users to enter longest possible value.
  • Use of Check boxes vs Radio buttons
    • Radio buttons are used when there is a list of two or more options that are mutually exclusive and the user must select exactly one choice.
    • Checkboxes are used when there are lists of options and the user may select any number of choices, including zero, one, or several. (e.g. Assign permissions)
    • A stand-alone checkbox is used for a single option that the user can turn on or off. (eg: Enable /Disable a user)
  • Paging
    • Paging should be introduced if user has to scroll down to see the list of records.
  • Default Values
    • The value(s) selected should be a frequently used by user


Title Bars and Icons:

Windows title bars have lots of uses for the users of our Applications in addition to the obvious ones of dragging and minimize etc they can be used to allow the user to easily identify which window out of a set of windows they require.

If possible choice a different icon for each type of window in your application. The users can then associate the icon with the function and you can remove the function of the window from the title bar. Leaving just the identifying data as the title bar.

Keyboard Control (Access Keys in HTML)

You may think this is an obvious topic that does not need a mention, but you would be surprised at how many applications that the keyboard functions of the user interface do not work at all or do not work well. Follow these standards to make sure your user interface is keyboard friendly.

Tab Order

Make sure the tab order of your form flows around the controls in the order that the user expects, if this sequence is not obvious ( it normally is ) then ask the user! Another aspect to consider is the focus starting point, a lot of the time the top left hand corner is the best starting point.

Views and Panels

These are new additions to the GUI interface and are a method for splitting a window into multiple resizable sections each dealing with a slightly different aspect to the application. These can be a great productivity aid for the user BUT make sure there is a keyboard equivalent to the mouse for changing the focus between the views.

Size is Everything

Although the contents of this article may seem obvious to some people, you would be surprised at the number of Windows that which although functionally correct look a complete disaster just because the developer did not take the time to get the sizes correct.


The first thing is buttons, try to keep the width of a button to a minimum, the prompt should be meaningful but where possible keep it less than 20 characters, use tool tips to add extra narrative if required. The golden rule of buttons is to make sure the width and height of all buttons on the same window are the same. All buttons in your application must be the same height, and if possible make them all the same width.

All controls should be lined up and buttons are no exception, most development tools provide a facility to do this automatically so use the tool, don't use your own judgment. If you have a dialog with buttons on the bottom then right align them with the edge of the rightmost button aligned with the right most edge of the right most control on the window.

Data Lists

The height of a header in a list of data that has a scrollbar should match exactly the height of an arrow header of the scroll bar, even one pixel either way looks very ugly. Try to make any data in the row have a pixel above and below for clearance, this will aid readability for the user. Make sure the right number of rows fits perfectly for the data list height, increase the size of the list a single pixel at a time and run the window, when a new row appears the size of the list is correct. Make sure the data fits the width of the control, only use horizontal scrolling when essential.


Make sure all of the fields on the window have the same height, unless the field allows a large description and wraps at the edge of the control. Where possible make a vertical lists of fields all the same width, if two or more fields are much shorter than the rest, double them up on a single line and right align then edge of the field to match the longer fields.

Make all the single line field prompts horizontally centered with the control, all other prompts should be aligned the same number of pixels from the top edge as the horizontally aligned prompts.

Make sure all dropdown lists have the same number of items available for selection and that the number of rows shown fit exactly, no little blank spaces where half a row could fit. Eight is a good number as it does not obscure too much of the display but allows the user a good view of the data. You should not use horizontal scrolling in a dropdown list. You can however make the width of the dropdown wider then the width of the dropdown control, this is especially useful when you want to show extra fields in the dropdown that are not displayed in the edit field.

Field Prompts

In a previous article on the use of colour in applications, I recommended not using colour for special meanings in your application, for example red backgrounds for mandatory columns. If you followed those guidelines your application will look more professional but you will have lost the indication to the user of which columns are mandatory.

These are two great uses for field prompts, you could extend them slightly but I would not recommend using more than 3 or 4 different prompts.

Visual Cues

When using an application there often little features that can aid a user in performing a task. Like all visual operations there is normally a manual method for performing the same operation. But the visual operation is simpler and quicker for the user and they can save time by using this feature.

However the visual operation is only quicker for the user if they know its there! So this article deals with how we can inform the user that these little features are available and how we can do this in a standard manner.

Your application should be able to inform the user about the feature or at least give them an indication that there may be some special feature that they may know about.


The easiest way to alert the user to a feature is by changing the pointer to something other than the standard mouse pointer

More Pointers

The following images are some examples of standard pointers you can use in your application to give the user a visual cue that your application will let them perform an action with the mouse that they may not know is available:

Practical Use of Colour

When To Use Which Colour

The following list describes common situations and the colours that should be used in those situations.

  • All windows backgrounds should be Button Face.
  • All command button backgrounds should be Button Face and the text should be Window Text.
  • Editable fields should have a background colour of Windows Background and the text should be Windows Text with a 3D lowered border. Do not use any other colours for special meanings for example; all red fields are mandatory. What if your user is colour blind and cannot see the red? The same goes for Listboxes, Checkboxes, Radio buttons and all the other standard controls.
  • Non Editable fields should have a background of Button Face to indicate to the user that the field is not editable. If you just disable the field they will try to click into it.
  • A List of multiple columns that are not editable but are used for selection purposes should have a background of Windows Background and a text colour of Windows Text with Dark blue being used to indicate the selected row. If multiple rows can be selected then blue indicates a selected row and a dashed rectangle indicates the current row. The header row of the list should be windows background with Windows Text for the text and a 3D raised border.
  • A list of multiple editable columns should have a background colour of Button Face and should follow the normal edit field rules described above for the editable columns.
  • Group boxes should always be 3D lowered with white and dark Grey for the high and lo lights of the rectangle. The text should be Windows Text.
  • Tab pages should be Button Face. Not a different colour for each tab!
  • Where possible any custom icons or images used in the application should make sure the background colour of the image is correctly masked to match the background colour of the are underneath the image. For example if you have a company logo with a Grey background on your logon window with a Windows Background for its colour then anyone who does not use Grey for their windows background will see an ugly Grey border around your image.
  • Following these simple colours consistently will help to give you application a more professional look and feel which the tired eyes your users will appreciate, of course there us much more to a professional looking GUI but that's a topic for another article.

A reserved-icons table containing standard approved icons.

Control Design

Controls are the visual elements that let the user interact with the application. GUI designers are faced with an unending array of controls to choose from. Each new control brings with it expected behaviors and characteristics. Choosing the appropriate control for each user task will as a guideline for control usage in your screens.

Acceptable date formats




DD Month, YYYY

Month DD, YYYY




All other characters are taken to be literals.


Suggested Default Font

The suggested font for use is an 8pt MS Sans Serif font. This is the default system font and it is recommended in the interface guidelines.

Font Settings

The following settings may be set and by opening the Application Painter and choosing the appropriate Tabs as listed below:

5.jpg 6.jpg 7.jpg

In most cases, you will not have to change the settings for the colors, font styles, or the effects.

Use of Color

In General

Color may be used with great effect to highlight important elements of the interface. However, too much color in one interface will generally lead to confusion on the part of the user. Use color sparingly, and with the following concepts in mind:

Use the following colors whenever possible:

Screen Layout - For Each Application

Start Application by accessing the URL.

The Loading message should show the application name and version number.

Login is necessary.

Logout from the application should result in an “Are you Sure” message box.

On each window, if the application is busy, then the hour glass should be displayed. If there is no hour glass (e.g. alpha access enquiries) then some enquiry in progress message should be displayed.

All screens should have a Help button, F1 should work doing the same.

For Each Window in the Application

If Window has a Minimise Button, click it.

Window Should return to an icon on the bottom of the screen.

This icon should correspond to the Original Icon under Program Manager.

Double Click the Icon to return the Window to its original size.

The window caption for every application should have the name of the application and the window name - especially the error messages. These should be checked for spelling, English and clarity, especially on the top of the screen. Check does the title of the window makes sense.

Check all text on window for Spelling/Tense and Grammar.

Use TAB to move focus around the Window. Use SHIFT+TAB to move focus backwards. Tab order should be left to right, and Up to Down within a group box on the screen. All controls should get focus - indicated by dotted box, or cursor. Tabbing to an entry field with text in it should highlight the entire text in the field.

The text in the Micro Help line should change - Check for spelling, clarity and non-updateable etc.

If a field is disabled (greyed) then it should not get focus. It should not be possible to select them with either the mouse or by using TAB. Try this for every greyed control.

Never updateable fields should be displayed with black text on a grey background with a black label.

All text should be left-justified, followed by a colon tight to it.

In a field that may or may not be updateable, the label text and contents changes from black to grey depending on the current status.

List boxes are always white background with black text whether they are disabled or not. All others are grey.

When returning return to the first screen cleanly i.e. no other screens/applications should appear.

In general, double-clicking is not essential. In general, everything can be done using both the mouse and the keyboard.

All tab buttons should have a distinct letter.

Text Boxes

Move the Mouse Cursor over all Enterable Text Boxes. Cursor should change from arrow to Insert Bar. If it doesn't then the text in the box should be grey or non-updateable. Refer to previous page.

Enter text into Box.

Try to overflow the text by typing to many characters - should be stopped Check the field width with capitals W.

Enter invalid characters - Letters in amount fields, try strange characters like +, - * etc. in All fields.

SHIFT and Arrow should Select Characters. Selection should also be possible with mouse. Double Click should select all text in box.

Option (Radio Buttons)

Left and Right arrows should move 'ON' Selection. So should Up and Down. Select with mouse by clicking.

An OptionButton, also known as a RadioButton, is a control that is represents a choice, usually of a property, or option, such as 'Read Only' or 'Sort Ascending'. It is advisable to avoid using a RadioButton to start an action such as 'Save' or 'Close'.

RadioButtons are grouped in logical sets of two or more and appear as a set of small circles with descriptive text to the right. The Windows 95 Interface Guidelines suggests using sentence capitalization; only capitalize the first letter of the first word, unless there are specific reasons otherwise (such as an acronym specific to the application, a proper noun, etc.). The text label can have multiple lines, and in this case top alignment with the button is suggested.

Each RadioButton within a group is mutually exclusive, i.e., only one option can be set on, the remaining buttons will be off.

A note of warning: Too many RadioButton choices may prove to be overwhelming. Refer to the “RadioButtons vs. Drop-down List Boxes” section as a guideline.

Check Boxes

CheckBoxes are controls used to set independent options; that is, one checkbox's state is independent of another checkbox. The control is a square with text, generally to the right. A checkbox generally has two states, on and off. When selected (on), they contain a checkmark; when they are not selected (off), they are empty. A third state commonly used to denote 'Unknown', displays as a filled box with a checkmark.

CheckBoxes can be grouped in a GroupBox, but that does not affect the CheckBoxes' behavior; they are still independent.

Command Buttons

If Command Button leads to another Screen, and if the user can enter or change details on the other screen then the Text on the button should be followed by three dots.

All Buttons except for OK and Cancel should have a letter Access to them. This is indicated by a letter underlined in the button text. The button should be activated by pressing ALT+Letter. Make sure there is no duplication.

Click each button once with the mouse - This should activate Tab to each button - Press SPACE - This should activate Tab to each button - Press RETURN - This should activate

The above are VERY IMPORTANT, and should be done for EVERY command Button.

Tab to another type of control (not a command button). One button on the screen should be default (indicated by a thick black border). Pressing Return in ANY no command button control should activate it.

If there is a Cancel Button on the screen, then pressing <Esc> should activate it.

If pressing the Command button results in uncorrectable data e.g. closing an action step, there should be a message phrased positively with Yes/No answers where Yes results in the completion of the action.

A CommandButton is a control, usually rectangular in shape, that has a label. The label can be text or graphic (A CommandButton with a graphic label is commonly referred to as a PictureButton). The label should represent the action the CommandButton is to start; i.e., a CommandButton with a label of Close will execute a close script. For buttons that will prompt the user for more information, the label text is generally followed by an ellipsis (. . . ).

Access keys, shortcut keys, and tab keys can be used to navigate among CommandButtons. Additionally the space bar and/or enter key can activate a CommandButton that has focus. All command buttons (with the exception of OK, Cancel and PictureButtons with no text) should have a unique shortcut key.

You can define a CommandButton as being the default button in a window. If you define a default CommandButton, the user's pressing the ENTER key when the focus is not on another CommandButton is the same as clicking the default button.

The normal appearance of a control is called the “up” state. Refer to the “Interaction with the User” section for additional guidelines.

Command Button Functionality

The definitions below are guidelines for common functionality of the most often used command buttons.

Drop Down List Boxes

Pressing the Arrow should give list of options. This List may be scrollable. You should not be able to type text in the box.

Pressing a letter should bring you to the first item in the list with that start with that letter. Pressing ‘Ctrl - F4’ should open/drop down the list box.

Spacing should be compatible with the existing windows spacing (word etc.). Items should be in alphabetical order with the exception of blank/none which is at the top or the bottom of the list box.

Drop down with the item selected should be display the list with the selected item on the top.

Make sure only one space appears, shouldn't have a blank line at the bottom.

Interaction with the User

Indicating Processing

Whenever the program has to spend significant time (more than about a quarter second) processing, the user should receive an indication that processing is occurring. There are basically 3 varieties of such indication that should be considered:

Communicating the site’s purpose

  • Show the logo in a reasonable size and noticebale location. The logo should be placed in the upper-left corner, which is usually the best placement for languages that read from left to right. Logo also acts as a link to the homepage

Communicating information about the organization

  • Include an “About Us” and “Contact Us” links. These links should be placed in the upper-right corner, which is a common placement for these links.


  • Locate the primary navigation area in a highly noticeable place
  • Don’t use made-up words for primary navigation choices


  • Give users an input box to enter search queries, instead of giving them a link to a search page. Also provide a link to an advance search tool.
  • Input boxes for search should be wide enough for users to see and edit standard queries on the site.
  • Don’t label the search area with a heading; instead use a “Search” button to the right of the box.


  • Allow users the opportunity to print or email content. Take users back to content at the end of each action.
  • Use consistent capitalization and other style standards. Design elements are fixed either by graphics or through Cascading Style Sheet. Content should be controlled by Cascading Style Sheet.


  • Differentiate links and make them scannable. Links are underlined and a different color from body text. Links also have a hover state.
  • Description rollovers used for practice area side navigation.
  • If a link does anything other than go to another web page, such as linking to a PDF, make sure the link explicitly indicates what will happen. Icons were used at the end of links to indicate that they are different.


  • Provide breadcrumbs as an indicator of the path the user has taken from the homepage. Breadcrumbs should appear on every page, except for the homepage and the print popup windows.


  • Provide a login area for registered users.
  • Users must be registered and logged in to gain access to Sahana.
  • Provide a “remember me” option. This option appears in login area.
  • Offer users a way to obtain lost passwords. This option appears in login area.
  • Offer users a way to register if they are unregistered. This option appears in login area.

Graphic Design

  • Make sure text is legible. Used high-contrast text and background colors so that type is as legible as possible. Black text on white background for content. Paragraph text set at 12px.
  • Avoid using all uppercase spelling in design elements. Mixed case is used.
  • Avoid horizontal scrolling at 800×600.
  • The most critical page elements should be visible in the first screen of content, without scrolling. Site ID, primary navigation, search and page title always appear without scrolling.
  • Use a liquid layout so the homepage size adjusts to different screen resolutions.

Popup Windows

  • Limit the use of popup windows.

Gathering User Data

  • Explain the customer benefits of registration on the homepage.

Website Layout

  • Provide a consistent layout for the website. The layout wireframe appears below. The layout is broken into the following five sections:

Fig : Website Layout

1. Site ID/Tool navigation area

2. Search area/list navigation area

3. Content area

4. Login Box

5. Footer area


  • The site is optimized for Internet Explorer 5.0 and above at 800×600 resolution (best viewed at 1024×768), and utilizes Cascading Style Sheets to increase flexibility and control over design elements.
  • Limited use of graphics to ensure faster performance on 56k modems.
  • Other technologies utilized include Macromedia Flash 5.0 and Adobe Acrobat4.0.

A list of design elements is listed below


The login area is located on the top of the right side navigation bar.

  • Remember me feature stores the user name and password so they don’t have to type it
  • Lost your password feature allows you to retrieve your password via email
  • Not registered yet? feature takes you to the registration Page


The on state of the home tab not only indicates to the user that they are on the homepage, but also introduces them to the tab navigation system.

A Registration area explains the benefits of registering. This area is visible at 800×600.

Homepage (after login)

This area indicates that user has registered and logged in.

This registration area becomes an area where the user can now access features available only to registered users.

General Screen Layout:

The first application screen is the first screen after sign-on. This screen must contain 80% of what user wants to do with the application. The other 20% of the functions to be done will be accessed via the menu bar or tool bar.

All buttons, labels, fields should be aligned vertically and horizontally and consistent across all applications.

Labels on buttons should be consistent and have same meanings across all applications and screens.

Use a colon and a trailing space after a text label preceding a text entry box or a list box. Do not use a colon after a text label in a group box or title bar.

Data Entry Fields -

Display-only fields do not have a border.

Updateable fields have a box border.

Length of the data entry field displayed should equal the commonly used length of the corresponding database field.

Use group boxes to contain a domain of choices or to gather a collection of related controls. If a control applies only to a section of the screen, that section of the screen plus related controls should be grouped in a box.

Design initially for monochrome. Use colors only to draw the user’s attention to something or to increase real world consistency. If there is no reason to use color, use black on white or black on light gray. 8-10% of people experience color confusion.

Ensure that the Help menu contains the following items: Contents, Search, Using Help, and About.

Change cursor to “hourglass” to indicate a short wait (2-10 seconds). Show the user a progress indicator on the status line for a long wait.

Use beeps for two things only:

  • To additionally warn user of potentially destructive action
  • To notify user long wait is over

First Line On Screen

Includes facilities for: Close Application; Title Bar; Minimize Application to Icon; Size Application.

Close Application:

Exits the application and ensures that all open files have been closed. Prompts to save changes.

Title Bar:

Position - Top line of screen

First Part - Should be Name of Application

Last Part - Should be description/name of file, record or object on screen.

Minimize Application to Icon:

Exhibits standard Windows minimize button behavior.

Size Application:

Exhibits standard Windows Size Application button behavior.

Second Line on Screen

This line should include Close File; Menu.

File Close:

Closes the current file or record and ensures that the file has been saved.

Menu Bar:

If applicable, use standard Windows menu items and place in the standard order: File, Edit, View, your custom options, Window, and Help. Name of the application’s main record (like Participant) can be substituted for File.

Place the most frequently used items within a menu group toward the top of the menu group.

Ensure that commonly used functions have shortcut keys on menu items and menu pull downs. Mnemonic Shortcut keys should use Alt plus unique letter indicated by underlined letter in menu bar item. Pushing mnemonic shortcut keys results in pulldown menu. Within a pulldown menu, press just the unique underlined letter.

Shortcut functions keys access functions within a menu item without first having to pull down a menu item. Use Ctrl plus unique letter. Only most often used functions should have shortcut key of this type. Indicate existence of shortcut in pulldown menu.

Ensure no mnemonics or shortcut keys conflicts with standard Windows mnemonics or shortcut keys.

Place an ellipsis (…) after a menu item to indicate that further dialog will appear before a function is executed.


If applicable, the third line should include an application tool bar.

Tool Bar:

Place most common accessed functions on a tool bar.

A user should recognize the function within 10 seconds of looking at the Icon.

Either descriptive caption should appear on toolbar button or a yellow popup tool tip should appear when the cursor hovers over tool bar Icon.


Last line is the status line.

Status Line:

First part - context sensitive help as cursor passes over areas on screen and/or short error or informational messages.

Last part - misc. status


Use group boxes to group related controls together.

Ensure each dialog box has a default non-destructive pushbutton that closes dialog box. The pushbutton should behave according to user expectations.

Ensure each dialog box has a title bar (same as name of menu item that invoked dialog), and do not allow resizing, minimizing, or maximizing of dialog boxes.

Re-use similar or the same dialog box to do functions common through out the application.

Place dependent controls beneath or to the right of the control they are dependent on.

Preserve user’s settings on common dialogs for as long as the current instance of the application is running.

Tab control should go top to bottom, left to right. Most common controls should be positioned first.

A reserved-icons table containing standard approved icons, such as the one shown in Figure

Choosing the appropriate control for each user task will result in higher productivity, lower error rates, and higher overall user satisfaction. Use the table in Figure as a guideline for control usage in your screens.

Icon must be used every time.

Guidelines for good UIs:

  1. Use Iterative design
    1. Involve the user in the design team
  2. Give the user a mental model of the system
    1. Not just a bunch of ad-hoc features
    2. Related to consistency
    3. Visual cues can help = “affordances”
  3. Good Graphic Design and Color Choices
    1. Unordered List Item
    2. Appropriately direct attention
    3. Group related objects (alignment, decorations)
    4. Balance and white space
    5. Maintain display inertia
    6. Few fonts and colors (5 to 7 colors)
      1. appropriate contrast
      2. some people are color blind (8% of males)
  4. Less is More (“keep it simple”)
    1. If complex to explain/document - redesign
    2. Concise language
    3. Avoid extraneous pictures and information
      1. Fewer options and menu choices
      2. Reduces planning time
      3. Reduces manual size, etc.
      4. E.g. in XXX product: “Show Cartouche”, “swap”
  5. Speak the User's Language
    1. Use common words and minimise jargon, e.g. folder rather than directory.
    2. Error messages and feedback refer to user objects
    3. Allow full-length names
    4. E.g. “Hit any key to continue”
  6. Use appropriate Mappings and Metaphors
    1. Task analysis to understand user's domain
    2. Metaphors can help or hurt
  7. Minimize User Memory Load
    1. Short-term memory = 7 +/- 2 items; 30 sec to 2 min
      1. unless interrupted
    2. Recognize, not recall (generate)
    3. Menus rather than type-in (but short enough)
    4. Prompts provide format
    5. Don't require retyping of remembered information
    6. Pervasive, generic rules (cut/paste)
    7. E.g. in Aegis, remembering altitude
  8. Be consistent
    1. Same command always have the same effect
    2. Locations for information, names of commands
    3. Size, location, color, wording, function, sequencing, …
    4. Following standards helps
    5. Seems easy, but often not followed. e.g. in XXX
      1. naming “F#1.C#1” vs. “F#1”, “C#1”
      2. line-style, fonts & color dialog boxes work differently for getting the current value
      3. consistent with industry standards: e.g., Copy
      4. prefix vs. postfix: “delete” vs. “moving object”
      5. Macintosh: deleting files vs. disks
  9. Provide appropriate feedback
    1. About what system is doing, and how input is being interpreted. “articulory” and “semantic”
    2. Response time:
      1. 0.1 sec for articulory
      2. up to about 4 sec for an operation
      3. Percent-done progress bars
    3. E.g. in XXX product,
      1. “really ungroup?” – loses associated behavior
  10. Clearly marked Exits
    1. Cancel buttons
    2. Make all user actions easily reversible (undo)
    3. Users (even experts) will make errors
    4. E.g. in XXX product,
      1. no way to get out of editing a text field
  11. Prevent errors
    1. Selection rather than entry
    2. Remove or grey-out illegal choices
    3. Confirmation
  12. Good error messages
    1. Help users when they are in trouble
    2. Opportunities for users to learn about the system
    3. Clear language; no codes
    4. Be precise. Not “syntax error”
    5. Constructively help the user solve the problem?(tell why the error happened and how to fix it)
    6. Be polite and not accusing; positive wording:
      1. Not: “FATAL ERROR”, etc.
    7. Blame the system, not the user
      1. “Unrecognized” vs. “illegal” command
    8. No humor or snide comments
    9. Easy error recovery
      1. E.g. in CMU CL: segvhandler: No mapping fault: 0x00e80000
      2. E.g. in XXX product: “can't save file” – why not?
    10. E.g., in YYY product: “SID: Failed MAC check on message”
  13. Provide Shortcuts
    1. For experienced users
    2. Command keys, macros, styles, recent files (Boomerang)
  14. Minimize modes
    1. Definition: same user action has different results
    2. Make unavoidable modes visible
    3. E.g. in XXX product, fillet uses invisible mode
    4. E.g. Typing “daytime” to a mail program
  15. Help the user get started with the system
    1. No more than 1 simple overview screen to get started doing real work
  16. Use cognitive directness
    1. Minimize mental transformations
    2. ^C rather than ESC-F7 for “Cut”
  17. Accommodate individual differences
    1. Novice and expert
    2. Handicapped users
    3. Customization

Top 10 mistakes in Web design

  1. Using frames
  2. Gratuitous use of bleeding-edge technology
  3. Scrolling text, marquees, and constantly running animations
  4. Complex URLs
  5. Orphan pages
  6. Long, scrolling pages
  7. Lack of navigation support
  8. Non-standard link colors
  9. Outdated information
  10. Overly long download times

QR Code
QR Code dev:gui_standards (generated for current page)