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

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

3. 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

4. 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

5. A MS Access Fill-in Form

6. 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

7. 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

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

9. 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

10. 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)

11. 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

12. 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??)

13. 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

14. 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

15. 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)

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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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.

23. 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

24. 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

25. 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

26. 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

27. 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.)

28. 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.)

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