Mechanism Level Design - continued Dialog boxes and fill-in forms Command language design Tightly-coupled windows (left over topic)

Dialog Boxes Combination of menus, buttons and fill-in techniques Example: Find/Replace and Font Dialogs

Dialog Boxes: How they work Superimposed over the main window Engages the user in a “side” conversation offering information requesting input When user is finished viewing/changing information, accept or reject the changes and exit the dialog Dialog box disappears and user returns to main window

Fill-in Forms: How they work An extreme case of a dialog box where most of the widgets are text entry fields Or: the main window of a database or data entry application Example: On-line shopping – page where shipping address and credit card details are provided Many similar design issues, choices and guidelines

A MS Access Fill-in Form

Dialog Boxes: Overused? Many designers use as primary interaction idiom User must constantly bounce back and forth Immediate and gross change to screen image is visually distracting Breaks the smooth flow of interaction between the user and the program

Dialog Boxes: When they should be used To concentrate information related to a single task or object (such as printing) To present infrequently used settings and functions To control advanced or dangerous facilities When a roomier setting is needed to present controls, making space for prompts and explanations

Dialog Boxes: Components Title Fields or other widgets Labels and prompts Terminating command(s)

Dialog Boxes: Types Bulletins – error, confirmation and information dialogs the most over-used Property dialogs (ex: font dialog) Function dialogs (ex: print dialog) Process/progress dialogs Also: modal v. modeless dialogs

Dialog Boxes: Design Guidelines I. Reveal conceptual structure Meaningful title Logical grouping and sequencing of fields Familiar field labels Optional fields clearly marked Explanatory messages for fields (prompts)

Dialog Boxes: Design Guidelines (cont.) II. Orchestration guidelines: Avoid overuse of modal dialogs Display close to appropriate items Avoid or minimize overlap Should disappear if main app is closed

Dialog Boxes: Design Guidelines (cont.) I. Offer consistent and clear affordances Offer “OK” and “Cancel” on all modal dialogs (except bulletins) Visually differentiate modeless dialogs from modal Don’t put close box on modal dialogs (why??)

Dialog Boxes: Design Guidelines (cont.) IV. Follow other usability heuristics Visually appealing layout of the form Visible space and boundaries for data-entry fields Convenient cursor movement Specify “tab order” in VB Consistent terminology and abbreviations Easy editing of characters and fields (now standard) Error prevention Use selection lists Signal coding of phone numbers, dates, etc. Error messages for unacceptable values Comprehensible instructions

Dialog Boxes: Design Guidelines (cont.) V. Internal Layout Guidelines Visually distinct title Top-left to bottom-right sequencing Consistent layouts (margins, grid, white space, lines, boxes) Consistent terminology, fonts, capitalization, justification Standard buttons (OK, Cancel) Error prevention by direct manipulation widgets

Design Choices for Text Entry Fields Insert vs. overtype mode Different forms of prompts: Date: _____________ (MM/DD/YY) Date: _ _ / _ _ /_ _ _ _ (01 – 31 – 2004) SS# _ _ _ - _ _ _ - _ _ _ _ Size ___ (8, 10, 12, 14, or 16)

Design Choices for Text Entry Fields (cont.) Validation options: Accept any input “Hot” validation – check each keystroke “Cold” validation – when to perform it? Validation feedback: modal dialog, tooltip, color coding

Guidelines for Text Entry Fields Visually distinguish text entry fields from text display fields Always use insert mode (or always overtype mode) Clue the user why validation has failed Follow text display guidelines, such as: Left-justify character fields, right justify numbers

Command Interfaces Benefits: power/expressiveness, efficiency, match to task, easy to customize for expert user Issues: human comprehension, learnability, memorability grep -v ^$ filea > fileb Elements of commands: Action Objects Options

Command Language Design Design Process Analyze functionality needed Task actions and objects Interface actions and objects (naming) Syntax for combining actions, objects, options Common Design Errors Excess functionality (too many objects and actions) Inconsistency due to uncoordinated design

Command Interface Design Guidelines Make frequently-used actions easy to perform Consistent terminology (naming and syntax for options) Consistent argument/option ordering (positional consistency) Meaningful names vs “codes” Grammatical consistency (part of speech) Keyword parameters

Command Language Structure Congruent design (meaningful opposites): Forward robot Robot back Hierarchical design (consistent syntax) Position arm higher Move arm down Congruent and hierarchical Move arm up Move arm down

Command Interface Design Guidelines (cont.) Famous (Carroll, 1982) “paper” experiment for robot languages: Hierarchical design Congruent design Subjects said they preferred non-hierarchical, congruent design. Performance was best for hierarchical, congruent design. But on-line test might differ due to longer hierarchical commands.

Command Naming (lots of studies) Guidelines: Avoid computer jargon, use domain jargon (Nielsen: speak the user’s language) use specific v. general terms (Black and Moran famous experiment showed infrequent terms worked better.) use distinct terms (avoid: sen, sea, sel) use congruent pairs use grammatical consistency

Command Abbreviations Abbreviation strategies: truncation delete  del vowel drop move  mv first-and-last quit  qt first of each word send mail  sm familiar (QTY, PCT) Phonetic view  vu

Command Abbreviations (cont.) BS recommends rule-based approach with secondary rule for handling conflicts. Experiments show: truncation rule is easier to remember fixed length abbreviations may be better do not incorporate common word endings teach initially using full names, then learn abbrevs. Should not be used in error messages

Tightly-coupled windows Used for: Structured applications with linked data sets Flexible browsing - overview and detail Pop-up annotations/tool tips Coordination techniques: Synchronized scrolling Dependent-windows opening Hierarchical browsing Dependent-windows closing Direct selection Save or open window state Two-dimensional browsing

Image Browsing and Tightly-coupled Windows Definition: show a graph, map or image in “over” view, with a field-of-view box that can be moved. Detailed view of the contents of the box appears in a linked window. Purpose: support display of large complex images (medical, geographic, design diagrams, etc.)

Image Browsing and Tightly-coupled windows (cont.) Design issues: zoom factor (between 5 and 30) zoom factor/box size (fixed or flexible) intermediate levels? (control of number of views) single-view zooming, fisheye view window placement (side by side most common) image update (continuous v. at end of move) coupling other interface widgets (sliders, etc.)

Image Browsing and Tightly-coupled windows (cont.) Classification of Image-oriented tasks Image generation Open-ended exploration (“browsing”) Diagnostic Navigation Monitoring