560 likes | 680 Views
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/. Unit E : Design Guidelines. A General Meta-Guideline
E N D
SEG 3210User 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/
Unit E: Design Guidelines • A General Meta-Guideline • Interaction Styles vs. Interaction Elements • Coding Techniques and Visual Design • Response Time • Feedback and Error Handling • Command-Based Interfaces • Menu Driven Systems • Keyboard Shortcuts • Forms-Based Interfaces • Organizing a Windowing Interface • Question and Answer Interfaces • Information Query Interfaces • Voice I/O • Natural Language Interfaces • Other Types of I/O • Localization and Internationalization • On-Line Help • Guidelines and Standards Documents
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
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
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
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
Command Language • Many guidelines for command languages also apply to: • • Voice I/O • • Natural language I/O • • Choice of menu and field names etc.
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
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)
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
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’
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
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
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
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
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!
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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’
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
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
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)
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.
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
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 errors Most 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
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
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)
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
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
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
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)
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
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
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
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