ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
1Unit E-Guidelines(c) elsaddik
SEG 3210
User Interface Design & Implementation
Prof. Dr.-Ing. Abdulmotaleb El Saddik
University of Ottawa (SITE 5-037)
(613) 562-5800 x 6277
elsaddik @ site.uottawa.ca
abed @ mcrlab.uottawa.ca
http://www.site.uottawa.ca/~elsaddik/
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
2Unit E-Guidelines(c) elsaddik
Unit E: Design Guidelines
1. A General Meta-Guideline2. Interaction Styles vs. Interaction Elements3. Coding Techniques and Visual Design4. Response Time5. Feedback and Error Handling6. Command-Based Interfaces7. Menu Driven Systems8. Keyboard Shortcuts9. Forms-Based Interfaces10. Organizing a Windowing Interface11. Question and Answer Interfaces12. Information Query Interfaces13. Voice I/O14. Natural Language Interfaces15. Other Types of I/O16. Localization and Internationalization17. On-Line Help18. Guidelines and Standards Documents
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
3Unit E-Guidelines(c) elsaddik
Interaction
• Communication between the user and the system• Some applications have very distinct styles of interaction.
• Some common interaction styles:• Command line interface
• Natural language
• Question/answer and query dialogue
• Form-fills and spreadsheets
• WIMP:• Windows• Icons• Menus• Pointers
• Eye-tracking
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
4Unit E-Guidelines(c) elsaddik
6. Command-Based Interfaces
• Way of expressing instructions to the computer directly:• function keys, single characters,
• short abbreviations, whole words, or a combination
When to create a command language?• Suitable for repetitive tasks• Better for expert users than novices• Offers direct access to system functionality• Command names/abbreviations should be meaningful
Typical example: the Unix system
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
5Unit E-Guidelines(c) elsaddik
6. Command-Based Interfaces: Example
File colours contains:
Sort them using:% sort colours
To store the output in a new file we do this: % sort colours > colours.sorted
red rojo
green verde
blue azul
white blanco
black negro
black negro
blue azul
green verde
red rojo
white blanco
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
6Unit E-Guidelines(c) elsaddik
6. Command-Based Interfaces: Example2
search for information in a file
the following command would give an alphabetical list of all persons within the file (telephone) whose name contains the string "Fred". % grep Fred telephone | sort
The symbol "|" is called "pipe." It pipes the output of the grep command into the input of the sort command
Alpha, Fred: 333-6565
Beta, Freddie: 656-0099
Gamma, Fred-George: 111-7676
Zeta, Frederick: 431-0987
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
7Unit E-Guidelines(c) elsaddik
Command Language
Many guidelines for command languages also apply to:
• Voice I/O
• Natural language I/O
• Choice of menu and field names etc.
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
8Unit E-Guidelines(c) elsaddik
Should a command language be like English?
• Use English lexicon (command names and keywords).• Both expert and novice users find this faster
• e.g. delete, save, search, replace• Don’t use full English grammar (sequence and rules of the
language)• English is not consistent and makes a command language hard to
learn• For textual commands, use English meanings for the
punctuation:• e.g. ‘.’ means end
• ‘;’ means end with more to follow
• ‘?’ means ‘unknown’
• But don’t rely on punctuation to carry meaning• i.e. the basic meaning should be clear to the user if punctuation were
stripped
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
9Unit E-Guidelines(c) elsaddik
Specificity Versus Generality
Infrequent, discriminating words insert delete
Frequent, discriminating words add remove
Infrequent, nondiscriminating words amble perceive
Frequent, nondiscriminating words walk view
General words (frequent, nondiscriminating)
alter correct
Nondiscriminating nonwords (nonsense)
GAC MIK
Discriminating nonwords (icons) abc-adbc abc-ab
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
10Unit E-Guidelines(c) elsaddik
Specificity Versus Generality
Black & Moran 1982 found out: (82 test subjects)• Infrequent, discriminating have:
• Faster learning process
• Superior recall • General words:
• Lowest performance• Nonsense words
• Did well (with small command sets, distinctive names are helpful even if they are not meaningful)
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
11Unit E-Guidelines(c) elsaddik
Specificity Versus Generality
• Specific command names tend to be better than general ones.• Users remember them longer
• Users need less help• e.g. ‘Send’ vs. ‘Transfer’• e.g. ‘Insert’ vs. ‘Add’
• But having different names for related commands is confusing• e.g. maybe the following have slightly different meanings
• ‘create’, ‘new’,
• in this case, pick one of these as the general command name
• ... and use command arguments or options to distinguish between variants
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
12Unit E-Guidelines(c) elsaddik
Command Language
• Command names should be familiar • For the most frequent commands, and where no ambiguity
would arise, consider allowing several synonyms to be used:• Users can guess names 10-15% of the time
• If three common English synonyms are allowed, users guess over 80% correctly
• e.g. quit, exit, bye, logoff, logout
• Command words should invoke the intended mental model and no other • Avoid words that can be ambiguous or alien to users
• e.g. ‘expunge’, ‘execute’, ‘kill’, ‘fatal’
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
13Unit E-Guidelines(c) elsaddik
Should a command language be ‘rich’ or ‘minimal’?
• Minimal?• There is only one way to perform an operation• There is no redundancy
• e.g. a language has ‘delete’ and ‘insert’.
• ... to replace one deletes then inserts
• Rich?• A language has many alternate ways to perform an operation
• e.g. ‘delete’ + ‘insert’
• ‘replace’ from position 1 to position 2
• ‘substitute’ pattern1 with pattern2
• Provide richness for the top 10% of the functionality and minimalism for the rest
• Avoid the temptation to add a variation because it is easy to add
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
14Unit E-Guidelines(c) elsaddik
Six Potential Abbreviation Strategies
• Simple truncation: • Use the first, second, third, etc. letters of each command:
• vi for visual, full-screen editor • Vowel drop with simple truncation:
• Eliminate vowels and use some of what remains:• cp for copying files
• First and last letter: • Since the first and last letters are highly visible, use them:
• ST for SORT• First letter of each word in a phrase:
• Use with a hierarchical design plan:• cd for change directory
• Standard abbreviations from other contexts: • Use familiar abbreviations:
• QTY for Quantity; PRT for Print or BAK for Backup• Phonics:
• Focus attention on the sound:• XQT for Execute
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
15Unit E-Guidelines(c) elsaddik
Command Language
• Avoid abbreviations that are too short:• e.g. one character
• It becomes hard to extend the language in future
Provide intelligent support to assist users to enter commands• Allow defaulting of parameters that are omitted• Allow command editing
• Direct editing using the mouse
• Redisplay of last command followed by cursor key editing• Allow semi-automatic completion of partial commands
• Emacs style tab-completion• pressing tab tries to find a suitable word to complete any abbreviated
entry• presents a menu if more than one possibility
• Allow semi-automatic spelling corrections• Provide a quick syntax reference
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
16Unit E-Guidelines(c) elsaddik
Spelling errors to try to correct
• All possible transpositions:• Haert Heart
• All possible one-letter replacements:• Cous Cows
• All possible one-letter insertions:• Hous House
• All possible one-letter deletions• Hueart Heart
• Insertion of space (1 word becomes 2)• Upto Up to
• Deletion of space (2 words becomes 1):• Specifi cation Specification
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
17Unit E-Guidelines(c) elsaddik
An algorithm for Spelling Check
Most of the time users will not make any mistake, so the word will be recognized.
When a word is not recognized, try the above transformations to see how many known words match.
If only one known word matches, use it.
If more than one word matches, present a menu (with a none-of-the-above option).
If no word matches, be polite!
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
18Unit E-Guidelines(c) elsaddik
7. Menu Driven Systems
• Menus build human abilities for:• Recognition
• Exploration and navigation• Problems with menus:
• They take time to pick from• Keys are faster
• They force structure on the user• Command languages and forms give more flexibility
• They can be impractical when there are too many choices• Dialogue boxes can be better
• Permanent menus take up screen real estate• e.g. menu bars
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
19Unit E-Guidelines(c) elsaddik
Standard types of menus
• Permanent• In a menu bar
• can access any command at any time
• the permanent information is the menu label
• In a form• e.g. list of radio buttons• permanent information is the
current value (property window of Visualbasic)
• In a palette or toolbar (action buttons)
• can access any command at any time
• permanent information is a menu item icon
• takes real estate and can be confusing
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
20Unit E-Guidelines(c) elsaddik
Standard types of menus
• Pull-down
• Popup (Contextual)• displayed by special mouse
button• Can access a command rapidly
without moving cursor
• Modal• Each menu is a complete
screen or web page
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
21Unit E-Guidelines(c) elsaddik
Gestural syntaxes for selecting a menu item:
Most operating systems now allow both
• Press-drag-release (Example UoO web)• Menu popped up by holding mouse button down while pointing at
the menu label
• Menu disappears if pointer is moved away from the menu or released on the label
• An item is selected if pointer released on it• Disadvantage:
• User may accidentally release button on wrong item
• It is tiring to hold menu button down
• Click position click (Example Powerpoint)• First menu click brings up menu
• Second menu click selects an item• Disadvantage
• Not intuitive how to get rid of menu
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
22Unit E-Guidelines(c) elsaddik
User strategies for choosing an item from a menu:
• Beginners:• Read all options, then decide
• Hence, keep menus small
• Intermediate:• Scan to desired item then select• Hence keep menus well organized and keep frequent items at top
• Expert:• Jump to item (knows where it is) and then select
• Hence keep same items in same positions at all times
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
23Unit E-Guidelines(c) elsaddik
Menu size guidelines
• Keep menus short• 7 +/- 2 items, groups or items in a group
• This does not tax human short-term memory
• Fewer than this forces more levels of depth
• More than this makes locating and choosing hard
• Keep hierarchies shallow• Avoid too many levels of nested submenus
• A single level of submenus is often suggested as the limit.• Some believe menus may occasionally go one or two steps deeper as
long as the number of items per level is few.
• Only less frequently used options should be more deeply nested
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
24Unit E-Guidelines(c) elsaddik
When there are too many items to fit in a menu structure
• Keep the most important items in menus
• Sacrifice by making menus longer, before making menus deeper.
• Provide dialog boxes and commands for the rest
• But consider allowing the user can tailor the system, changing the contents of menus
• Some users prefer menus to dialog boxes
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
25Unit E-Guidelines(c) elsaddik
Example nested menu
• Problems with nested menu:• Several click to find out and/or
set the state• Cannot find out all the state at
once
• Advantages over a dialog box• Less real estate• Often faster to display and
remove
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
26Unit E-Guidelines(c) elsaddik
Menu guidelines to assist the user
• When standards or conventions exist, follow them• e.g. ‘file’, ‘edit’ and ‘window’ menus
• Keep menus self-explanatory• Give items meaningful labels
• Be consistent in grammar and pattern in sets of menu labels• e.g. the following set of labels is bad!• ‘up’, ‘go down’, ‘forward’, ‘reverse’
• Ensure all items correspond to the name of the menu• i.e. menu items should be meaningfully organized• e.g. on an ‘insert’ menu, all items should be things to insert
Ensure items only correspond to the name of this menu (not any other)
• i.e. make sure the each item can only logically be in one place• rename the item or the menus if necessary• Prevent users from searching the wrong menu
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
27Unit E-Guidelines(c) elsaddik
Menu guidelines to assist the user
• Use checkmarks to show state of toggles• Use a triangle to show when there is a submenu• Use an ellipsis to show when the action cannot be completed
without further input• e.g. ‘save as...’
• Means a modal dialog box must be filled in
• But don’t use an ellipsis when just opening a new non-modal window
• Group related menu items• Separate groups by horizontal lines
• This allows users to focus attention
• Good grouping can allow the total number if items to be increased to 15-20
• Disable items that are not valid in the current context• ‘Grey them out’
• Do not remove them unless the user persistently works in a context where a set of items is never valid (e.g. beginner mode)
• Provide tool tip help even on disabled items
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
28Unit E-Guidelines(c) elsaddik
Menu guidelines to assist the user
• Provide a facility to back up to the previous level in multi-level modal menus
• E.g. to go to the hope page or parent page• Provide visible feedback so users know where they are in a
menu hierarchy• e.g. when displaying a lower-level web page
• Allow the user to pick from higher levels directly
• For screens displayed as a result of menu choices, display the menu item that led to the screen
• The above always ensures the user keeps a mental model of where they are
• Use modal menus only for systems that are used for searching through categories of information
• E.g. directories on the web
• Design most applications so users have access to all commands at all times
• Consider providing ‘beginner’ menus with fewer choices
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
29Unit E-Guidelines(c) elsaddik
Menu guidelines to assist the user
• Provide a way of accessing help on each menu and item• This facilitates exploring and building the user’s mental model
• Dynamic tool-tip/balloon help when cursor pauses over the item
• One-key access to context-sensitive help about whatever the cursor is pointing to
• Allow direct picking of items from menus• ... as opposed to ‘choose the number’ of the menu item
• On a character-based display, use cursor keys to select.
• This only works if the number of items is few
• Where there are too many items to allow cursor movement, preferably use mnemonic alphabetic choices
• as well as cursor movement
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
30Unit E-Guidelines(c) elsaddik
Menu guidelines to assist the user
• Help the user perform frequent and repetitive actions• Place the most used menu items near the top
• If frequencies are equal, order by natural sequence or sequence performed in the task
• e.g. East to west provinces are a natural sequence• If still equal, order alphabetically• But never sacrifice good grouping
• Provide keyboard shortcuts and display them on the menu• Allow tailoring of shortcuts
• Provide pop-up menus for key actions• Especially if context sensitive• i.e. action depends on what is selected• But in general, permanent menus are better
• Consider providing history tracking:• When a menu is displayed, place the cursor on the most recent item
chosen from this menu• Palm OS does this
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
31Unit E-Guidelines(c) elsaddik
Menu guidelines to assist the user
• Use menus in forms wherever there are 3-20 possible data values in a field
• This eliminates error checking
• ... and helps the uncertain user
• But consider combo boxes in date-entry intensive applications
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
32Unit E-Guidelines(c) elsaddik
8. Keyboard Shortcuts
Keyboard Shortcuts• A key combination that can be pressed to do a task, instead of using the
mouse to select a pull-down menu option• In other words:
• Keystroke combinations that activate a menu item from the keyboard even if the menu for that command is not currently displayed
• Keyboard shortcuts (usually) consist of: • a modifier key and • a character key
• like Control-Z, plus a few special keys such as F1 and Delete
Mnemonics• Another keyboard alternative to the mouse• Underlined alphanumeric character in:
• a menu title, menu item, or other interface component. • Activate the equivalent command by simultaneously pressing:
• The Alt key and • The character key that corresponds to the underlined letter or numeral
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
33Unit E-Guidelines(c) elsaddik
8. Keyboard Shortcuts Vs. Mnemonics
• Unlike mnemonics, keyboard shortcuts:• Do not post menus
• They perform the indicated actions directly
• Since all keyboard shortcuts are available at all times, you cannot reuse them as you do mnemonics
• Keyboard shortcuts & Mnemonics• Can save time and the effort of switching from the keyboard to the
mouse to execute simple commands
• Sometimes it’s just too inconvenient to move the hands off the keyboard and look for the mouse.
• Working with a laptop ‘pointer device’
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
34Unit E-Guidelines(c) elsaddik
8. Guidelines for Keyboard Shortcuts
• Limit the number of keyboard shortcuts• Provide alternate means of accessing the same functions
• - i.e. menus• Do not provide a shortcut for all commands• Display keyboard shortcuts using the standard abbreviations for key
names:• such as Ctrl for the Control key, separated by hyphens
• Do not use the Meta key (the Command key on the Macintosh platform) for a keyboard shortcut
• It is not available on some target platforms• Because each platform has its own standard keyboard shortcuts,
ensure that any new keyboard shortcuts you have created are compatible with existing shortcuts on all your target platforms
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
35Unit E-Guidelines(c) elsaddik
Common Mnemonics
Menu Titles Menu Items
File New, Open, Close, Save, Save As, Page Setup, Print, Exit
Edit Undo, Redo, Cut, Copy, Paste, Delete, Find, Find Again, Select All
Format Font, Style, Size, Bold, Italic, Underline, Align Left, Align Center, Align Right
View Large Icons, Small Icons, List, Details, Sort By, Filter, Zoom In, Zoom Out, Refresh
Help Contents, Tutorial, Index, Search, About Application
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
36Unit E-Guidelines(c) elsaddik
Common Shortcuts
• Ctrl-N New (File menu)
• Ctrl-O Open (File menu)
• Ctrl-W Close (File menu)
• Ctrl-S Save (File menu)
• Ctrl-P Print (File menu)
• Ctrl-Z Undo (Edit menu)
• Ctrl-Y Redo (Edit menu)
• Ctrl-X Cut (Edit menu)
• Ctrl-C Copy (Edit menu)
• Ctrl-V Paste (Edit menu)
• Delete Delete (Edit menu)
• Ctrl-F Find (Edit menu)
• Ctrl-G Find Again (Edit menu)
• Ctrl-A Select All (Edit menu)
• Ctrl-H Replace (Edit menu)
• Ctrl-B Bold (Format menu)
• Ctrl-I Italic (Format menu)
• Ctrl-U Underline (Format menu)
• Ctrl-L Align Left (Format menu)
• Ctrl-E Align Center (Format menu)
• Ctrl-R Align Right (Format menu)
• F1 Help
• F5 Refresh
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
37Unit E-Guidelines(c) elsaddik
Common Shortcuts
• How to move the current window or dialog box, to a different position on the screen, without using the mouse?
• Press (SHIFT + ALT + SPACEBAR) then press M • Move the window or dialog box using the up/down/left/right arrows then press (ENTER)
• How to resize the current window without using the mouse?
• Press (SHIFT + ALT + SPACEBAR) then press S • Move the window using two of the up/down/left/right arrows then press (ENTER)
• How to switch between multiple applications, which are open at the same time?
• Press (ALT + TAB) or • Press (ALT + ESC)
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
38Unit E-Guidelines(c) elsaddik
9. Forms-Based Interfaces
• A form is a screen containing labeled fields that are to be filled in by a user, generally by typing or sometimes by making menu choices
• The user is presented with a form where the various portions must be filled-in
A form can be created by using:• User-Typed strings:
• Validation is necessary
• The designer could indicate the desired syntax visually (i.e., the maximum length of a string, date DD/MM/YY).
• User choices from a list• All allowable choices can be itemized
• The use of an iconic menu for example, will reduce errors due to typing.
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
39Unit E-Guidelines(c) elsaddik
9. Forms-Based Interfaces
Key task for the designer:• Effective screen layout
Avoid clutter
Follow a consistent style throughout the system, but keep screens distinct so you can tell them apart
Tasks for the user:• Entering information as quickly and accurately as possible
Include only information that is truly necessary for the user task(s)
• Understanding what must be entered• Searching for or looking up particular information• Verifying the correctness or completeness of information• Confirming to see if information is relevant or correct
Help the user feel in control
• Making correct decisions Include all information necessary for decision making
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
40Unit E-Guidelines(c) elsaddik
General tips for designing data entry fields
• Allow unlimited numbers of characters in fields, where possible• If user keeps typing, scroll field.
• Where limited-length fields are essential:• Ensure users can tell the length
use a fixed-width font• Avoid combining letters and numbers in a coding system
• Users will be prone to transcription errorsMost common errors:
• O (letter) vs. 0 (number)• I (letter) vs. 1 (number)• B (letter) vs. 8 (number)• Z (letter) vs. 2 (number)
• Provide system completion of unambiguous partial input• correct spelling
• allow abbreviations
• allow tab-completion with display of partial menu• But normally ask the user to confirm the correction
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
41Unit E-Guidelines(c) elsaddik
General tips for designing data entry fields
• Allow upper or lower case input:• Abed = ABED = abed
• Allow any format for date input:• problem with date like: 05.07.70
• Is it: July, 5th 1970 or May, 7th 1970 ??• Allow users to enter any unit of measurement
• e.g. ‘in’, ‘cm’ etc.• perform conversions automatically
• Do not require leading zeros• Allow decimals, integers and fractions for non-integer values
• Convert internally• Pre-fill fields with default values where possible: Either …
• Previously entered values for this record• i.e. when editing data loaded from a database
• Historical defaults (when not displaying a record)• What this user has most recently entered• What this user usually enters
• ‘Reasonable value’ defaults• E.g. ‘Canada’ for the country• Visually distinguish previously entered data from other default values
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
42Unit E-Guidelines(c) elsaddik
General tips for designing data entry fields
• Ensure frequently entered items can be rapidly typed• e.g. ‘y’ and ‘n’ to set a Boolean field
• even when there is a check box• Follow consistent justification rules:
• Always left justify text input and codes
• Align decimal values to the decimal point
• Right justify other numeric values (that are not codes nor contain a decimal point)
• Provide ‘buttons’ to increment or decrement numbers in fields or cycle through sets of values
• For numbers that will be adjusted through a wide range, provide sliders or gauges
• SEE Example:
Applet (Disk scheduling)
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
43Unit E-Guidelines(c) elsaddik
Tips to help users choose from discrete sets of values
These are often stored internally as ‘codes’ that are the identifiers of real things• E.g.
• Product code
• Postal code
• Province code
• Credit card number
• SIN• Reduce use of codes to make an interface more direct
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
44Unit E-Guidelines(c) elsaddik
Tips to help users choose from discrete sets of values
• Automatically break up long codes into 3-4 character chunks• Telephone number: ( _ _ _ ) _ _ _ – _ _ _ _ (613) 562 – 5800
• Social Security Number: _ _ _ – _ _ _ – _ _ _ (000 – 000 – 000)
• Times: _ _ : _ _ _ _ (11:30 AM)
• Date: _ _ / _ _ / _ _ _ _ (03/21/69 indicates March, 21 1969)
• provide an example to the right of the entry field
• Let the curser jump to the next field
• But beware of foreign numbers that may have different standard patterns
• Don’t constrain input, just help clean it up• Add the spaces or dashes if the user omits them
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
45Unit E-Guidelines(c) elsaddik
Tips to help users choose from discrete sets of values
• Use the following widgets to avoid users having to memorize and enter codes
• When one item can be picked:• Lists / Combo boxes / Field menus
• When there are very many items• When the items can vary from run to run
• Radio buttons (exclusive-or)• Take up more space
• When several items can be picked:• Check boxes• Lists that allow multiple choices
• Take up more space
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
46Unit E-Guidelines(c) elsaddik
Tips to help users choose from discrete sets of values
If strange codes must be stored internally, translate them into usable mnemonic values on the screen• e.g. if 1-13 are used internally for province/territory codes, allow
alphabetic names• Translate as needed to internal values
• Provide graphical feedback about the currently chosen option (if possible)
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
47Unit E-Guidelines(c) elsaddik
Tips about field captions, labels and descriptive text
Keep field labels (sometimes called prompts) short• e.g. ‘Home address:’ rather than• ‘Enter home address’
Keep labels unambiguous & Meaningful• e.g. ‘Required delivery date’ rather than• ‘date’
Distinguish captions from input fields• input fields should be the only ones that are white with a box around
them
Use a mixture of upper and lower case in text• Avoid ALL CAPS:
• HOME ADDRESS Home address• It is slower to read and distracting (it shouts)
Where formatting of input is important, provide an example or format cue to the right of the entry field• e.g. (Last, First Middle)
Provide tool tips or balloon help text for each field.• This appears at the bottom of the screen when the cursor is in a field • As with menus
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
48Unit E-Guidelines(c) elsaddik
Tips about field captions, labels and descriptive text
Make instructions or descriptive text simple and clear• Use short sentences and words (5th grade reading level)• Use positive expressions, not negative
• Bad: Do not press <enter> until data is entered
• Better: Enter data, then press <enter>• Use active voice
• Bad: The message is sent by pressing <enter>
• Better: To send message, press <enter>• Keep instructions in chronological order
• Bad: Press <enter> after typing name
• Better: Type name, then press <enter>• Describe separate actions in separate sentences
• Bad: Enter data and press <return>
• Better: 1) Enter data 2) Press return to accept
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
49Unit E-Guidelines(c) elsaddik
Tips about field captions, labels and descriptive text
Make instructions or descriptive text simple and clear• When describing actions, describe consequences
• Bad: Press <return> when done
• Better: To add to database, press <return>• Describe results before actions
• Bad: Press <return> to add to database.
• Better: To add to database, press <return>• Keep paragraphs short
• 2-4 sentences• Separate paragraphs by one blank line• Keep line length 26-50 characters• If you use columns, place 4-5 blank characters between
columns• Avoid hyphenation (Tele-phone Telephone ) • Use indentation (point form) to organize text
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
50Unit E-Guidelines(c) elsaddik
Tips about arranging sets of fields
Group fields or other widgets when there are more than 7 in a dialog or window• Keep groups thematically unified• Make groups visually distinct
• Separate using lines and plenty of extra white (empty) space
• Use shading or colour behind groups• Consider labelling groups• Don’t have too many groups (3 - 5 is good)
If a dialog is still cluttered (confusing) after grouping, consider using multiple screens• Especially for beginners• But keep related items on the same screen
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
51Unit E-Guidelines(c) elsaddik
Tips about arranging sets of fields
Order items and groups logically• (Avoid random groupings)
• Use natural ordering where possible (e.g. standard order in addresses)
• Group alphabetically as a last resort
Only display screen elements which the user currently and definitely needs to see• Hide elements that are only sometimes needed
• Have them appear when the system can tell they are truly needed• I.e. avoid forcing users to decide about interrelationships
among fields• e.g. If field A has ‘4’ then field B must be filled in
• Have Field B automatically appear in real time when field A is filled in
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
52Unit E-Guidelines(c) elsaddik
Tips about arranging sets of fields
Align sets of fields consistently• Align the left sides of input fields• Align the right sides of captions (followed by a few pixels then
the input field)• Especially if captions differ substantially in length
Indicate when fields are optional• e.g. using a * for the mandatory fields
• But question why you are gathering the optional data* Family name: ___________________* Other names: ______________________ * Address: ____________________
____________________* Telephone: ______________________
Sex: ___Data of Birth
yyyy/mm/dd): _______________ Social Ins. Number: _______________
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
53Unit E-Guidelines(c) elsaddik
Tips to aid the user work within a screen
When a form is first entered, place the cursor over the most likely first input position• Should normally be the first field in the top left corner
• Unless pointing out the position of an error
Always allow the user to go back and edit already-entered data
Use tab and tab-back (shift-tab) for motion between fields
Place fields that will not change at the end so user does not have to tab through them• Optional fields• Fields with rarely changed default values
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
54Unit E-Guidelines(c) elsaddik
Tips to aid the user work within a screen
Ensure the text cursor can only rest on editable (unprotected) fields• And make sure protected fields look visually distinct
Where there are columns of similar data, arrange tab order to be column-by-column if possible• i.e. down the left, then down the right
When each line contains a record, and each record has several editable fields, tab order should be a record at a time• i.e. left-to-right, then top down
Place instructions at the top of a form• When it is necessary to describe how to use a form• (See also discussion of how to display error messages, in the
section on error handling)
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
55Unit E-Guidelines(c) elsaddik
Tips to aid navigation between dialogs
Provide navigational instructions in the same place on all dialogs• i.e. where to go next, what to do when done• Place at the bottom, unless users typically just glance at
screens
In on-screen navigational instructions• Be brief• Use consistent style• Indicate how to go back• Indicate where going back would go
• e.g. ‘To return to inventory items, press ESC’
Provide on-line help about each screen
ww
w.s
ite.
uo
ttaw
a.ca
/~el
sad
dik
ww
w.e
l-sa
dd
ik.c
om
56Unit E-Guidelines(c) elsaddik
Tips to aid navigation between dialogs
Label each dialog clearly• Indicate how the user got here• Indicate the page number of multi-page forms (e.g. wizards)
Ensure similar dialogs look sufficiently different to prevent confusion• A label is not enough
• e.g. ‘employee information’ vs. ‘customer information’
Ensure data loaded from the database looks different from data being newly entered or modified• - E.g. use a different font, colour, boldness etc