mechanism level design - continued dialog boxes and fill-in forms command language design...

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