mechanism level design - continued dialog boxes and fill-in forms command language design...
TRANSCRIPT
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 windowEngages the user in a “side” conversation
offering informationrequesting 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 applicationExample: 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 isvisually distracting
•Breaks the smooth flow of interaction betweenthe user and the program
Dialog Boxes: When they should be used
•To concentrate information related to a single task orobject (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 dialogsthe 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 ProcessAnalyze functionality neededTask actions and objectsInterface actions and objects (naming)Syntax for combining actions, objects, options
Common Design ErrorsExcess 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 robotRobot back
Hierarchical design(consistent syntax)
Position arm higherMove arm down
Congruent and hierarchicalMove arm upMove 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 secondaryrule for handling conflicts.
Experiments show:truncation rule is easier to rememberfixed length abbreviations may be betterdo not incorporate common word endingsteach 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