Mechanism Level Design continued

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
• Dont 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 gt 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
Hierarchical design (consistent syntax) Position
arm higher Move arm down
Congruent design (meaningful opposites)
Forward robot Robot back
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 users 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. Experiment
s 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