SEG 3210 User Interface Design & Implementation

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

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 Mnemonics

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

SEG 3210 User Interface Design & Implementation