CSC417 Lecture08

CSC417: Human Computer Interaction
Lecture 08: Designing and

Building Visual Interfaces II
Dr. Charbel T. Fares

charbelfares@usek.edu.lb
Design of Everyday Things
3
41 BC: Emperor tired of
loosing to the Gauls
Win me the
Chariot Race
Lecture 08 - CSC417 © Dr. Charbel Fares

4
Advisor intuitively finds a
solution
Hmmm……
AHA!
The Wind!

5
The Chariot Race (1)

Yes!!!
Nuts…
Notice
aerodynamic
efficiency of
the faster
chariot

6
The Chariot Race (2)

But, in maneuvering
for position on the Ooops Har,
turn… … har…
- The DRIVER makes an error!!!

- Or was it the DESIGNER???

7
Human Factors Engineered

Boadiceaised as well
This should
 do it…

8
Example: Tractors (1)

high center
of gravity
 Early design
narrow front
 Terrain wheel base
 rough
 hilly
 Farmer
 works long hours
 works quickly
9

 Results:

10

 Solution of redesign:
 roll cage
 low center of gravity
 wider wheel bases

11
So what does this teach us?

 Lesson 1
 many failures of human-machine system result from designs
that don‟t recognize peoples‟ capabilities and fallibilities.
 This leads to apparent machine misuse and human error
 Lesson 2
 good design always accounts for human capabilities.
 How you can train yourself
 look for examples of „human error‟
 critique them for possible „design error‟
 propose designs that limit / remove these errors
12
Why should we care about
Design? (1)
 Past
 manufacturers had little incentive to emphasize
usability
 customers have no experience until after they
buy the product
 early technology adaptors were „flexible‟
 willing to put up with annoyances
 consequences of bad design typically small (do
not bother a lot)
13
Design? (2)
 Today: Usability sells

 product reviews emphasize usability (e.g.,
Consumer Reports)
 customers have used related products, and can
often download trial versions (including
competitors)
 today‟s users are impatient and intolerant of bad
design
14
Design? (3)
 consequences of bad design now large
 costly errors in serious systems (e.g., financial
institutes)
 widespread effects (e.g., incorrect billing, failures)
 life-critical systems (medical, air traffic control)
 safety (in-car navigation systems)
 Professionalism
 software engineers are designers
 we are ultimately responsible for the products we build
Dialog Design
16
Dialog Styles
1. Command languages
2. WIMP - Window, Icon, Menu, Pointer
3. Direct manipulation
4. Speech/Natural language
5. Gesture, pen, VR

17
1- Command Languages
 Earliest UI interaction style
 Examples
 MS-DOS shell
 UNIX shell

18
CL Attributes
 Work primarily by recall, not recognition
 Heavy memory load
 Little or nothing is visible
so…
 Poor choice for novices

but...

19
CL Attributes
 Advantages for experts
 Speed, shortness
 Can express actions beyond a limited set
 Repetition, extensibility (scripting and macros)
 Easier implementation, less overhead
 Power

20
CL Dangers
 With added power, comes added
responsibility and danger
 UNIX
 % rm -r *: Deletes every file that you have, and you
can‟t get them back
Avoid excess
functionality
21
CL Design Goals
 Consistency
 Good naming and abbreviations

22
Consistency
 Provide a consistent syntax
 In general: Have options and arguments expressed the
same way everywhere
 UNIX fails here because commands were developed by
lots of different people at different organizations
 No guidelines provided
 Order: in English Subject Verb Object
 Terminology: Same concept expressed with same
options; ex: forward/backward, next/prev
 Ordering: keep the same order
23
Names and Abbreviations

 Naming: (Specificity versus Generality)
 General words
 More familiar, easier to accept
 Specific (typically better)
 More descriptive, meaningful, distinctive

24
Abbreviations
 Abbreviations allow for faster actions
 Expert performance begins to be dominated by
motor times such as # of keystrokes
 Not good idea for novices
 Allowed but not required

25
Picking Good Abbreviations

 Strategies
 Simple truncation (works best, but conflicts)
 Vowel drop plus truncation (avoid conflicts)
 First and last letters
 First letters of words in a phrase
 Standard abbrev from other contexts
 qty, rm, bldg
 Phonics
 be4
26
2- WIMP
 Focus: Menus, Buttons, Forms
 Predominant interface paradigm now (with

some direct manipulation added)
 Advantages:
 ?

27
Menus
 Key advantages:
 1 keystroke or mouse operation vs. many
 No memorization of commands
 Limited input set

28
Menus
 Many different types
 pop-up
 pull-down
 radio buttons
 pie buttons
 hierarchies

29
Menu Items
 Organization strategies
 Create groups of logically similar items
 Cover all possibilities
 Ensure that items are non-overlapping
 Keep wording concise, understandable

30
Recommendations used for
Menus
 Adjust the structure of the menu to the one
of the activity.
 Minimize the size of menus.
 Organize first the menu in width and
minimize its depth.
 Organize menus according to their usage.

31
Presentation Sequence
 Choices
 Alphabetical
 Group related items
 Frequently used first
 Most important first

32
Presentation Sequence
 One possible methodology (first->last)
 Natural order (if exists)
 Frequency of use
 Order of use
 Categorical
 Alphabetical

33
3- Direct Manipulation
Definition:
1) Continuous visibility of the objects and
actions of interest
2) Rapid, reversible, incremental actions
whose effect is immediately noticeable
3) Replacement of command language syntax
by direct manipulation of object of interest
(physical actions, buttons, etc.)

34
Direct Manipulation
 Examples
 WYSIWYG editors and word processors
 Video games

35
Direct Manipulation Essence

 Representation of reality that can be
manipulated
 The user is able to apply intellect directly to

the task
 The tool itself seems to disappear

36
Direct Manipulation Advantages

 Easier to learn & remember, particularly for
novices
 Direct WYSIWYG
 Flexible, easily reversible actions helps
reduce anxiety in users

37
Direct Manipulation Advantages

 Provides context & instant visual feedback
so user can tell if objectives are being
achieved
 Exploits human use of visual spatial cues
 Limits types of errors that can be made

38
Direct Manipulation Problems (1)

 Screen space exhaustive (info not all that
dense)
 Need to learn meaning of components of
visual representation
 Visual representation may be misleading
 Mouse may be slower than typing
 Not self-explanatory (no prompts)

39
Direct Manipulation Problems (2)

 Not good at
 Repetition
 History keeping (harder)
 Certain tasks (Change all italics to bold)
 Abstract elements (variables)
 Macros harder

40
3- Speech and Natural Language

41
When to Use Speech

 Hands busy
 Mobility required
 Eyes occupied
 Conditions preclude use of keyboard
 Visual impairment
 Physical limitation

42
Speech Input
 Speaker recognition
 Speech recognition
 Natural language understanding

43
Speaker Recognition
 Tell which person it is (voice print)
 Could also be important for monitoring meetings,

determining speaker
44
Speech Recognition
 Primarily identifying words
 Improving all the time

 Commercial systems:
 IBM ViaVoice, Dragon Dictate, ...

45
Recognition Dimensions
 Speaker dependent/independent
 Parametric patterns are sensitive to speaker
 With training (dependent) can get better
 Vocabulary
 Some have 50,000+ words
 Isolated word vs. continuous speech
 Continuous: where words stop & begin
 Typically a pattern match, no context used

46
Recognition Systems
 Typical system has 5 components:
 Speech capture device - Has analog -> digital converter
 Digital Signal Processor - Gets word boundaries, scales,
filters, cuts out extra stuff
 Preprocessed signal storage - Processed speech
buffered for recognition algorithm
 Reference speech patterns - Stored templates or
generative speech models for comparisons
 Pattern matching algorithm - Goodness of fit from
templates/model to user‟s speech

47
Errors
 Systems make four types of errors:
 Substitution - one for another
 Rejection - detected, but not recognized
 Insertion - added
 Deletion - not detected

48
Natural Language Understanding

 Putting meaning to the words
 Input might be speech or could be typed in
 Artificial Intelligence problems

49
Speech Recognition and Natural
Language Advantages
 Easy to learn and remember
 Powerful
 Fast, efficient (not always)
 Little screen real estate

50
Speech Recognition and Natural
Language Disadvantages
 Doesn‟t work good enough yet
 Assumes knowledge of problem domain
 Not prompted, like menus
 Requires typing skill (if keyboard)
 Enhancements are invisible
 Expensive to implement

51
4- Pen and Gesture

52
PDAs
 Becoming more common and widely used
 Smaller display (160x160), (320x240)
 Few buttons, interact through pen
 Improvements
 Wireless, color, more memory, better CPU,
better OS

53
Input
 Pen is dominant form
 Three main techniques
 Free-form ink
 Soft keyboards
 Recognition systems
 Also can connect keyboard

54
Free-form Ink
 Ink is the data, take as is
 Human is responsible for

understanding and
interpretation
 Like a sketch pad

55
Soft Keyboards
 Common on PDAs and mobile devices
 Presents a small
diagram of keyboard

56
Handwriting Recognition
 Lots of systems (commercial too)
 Different languages: English, French, etc.
 Not perfect, but people aren‟t either!
 OCR (Optical Character Recognition)

57
Recognition Issues
 Off-line vs. On-line
 Off-line: After all writing is done, speed not an issue,
only quality
 On-line: Must respond in real-time
 Bitmapped vs. Vectorized

 Bitmapped: Usually off-line, like OCR
 Vectorized: On-line, uses angle, direction, speed,
pressure, acceleration, etc.

Preventing Errors
An ounce of prevention...
59
Errors
 Errors
 Avoiding and preventing
 Identifying and understanding
 Handling and recovering

60
User-Computer Dialog
 Three phases
 Read-scan phase -- Perceptual errors
 Think phase -- Cognitive errors
 Respond phase -- Motor errors

61
Perceptual Errors
 Result from insufficient or poor perceptual cues
 Display of objects that are visually similar
 Invisible or poorly expressed states
 Failure to capture user‟s attention
 Lack of perceivable feedback

62
Cognitive Errors
 Caused by exhausting the memory and
problem solving capabilities
 due recall memory
 Lack of or poor mnemonic aids
 Inconsistency
 Lack of context or status info
 Mental calculations and translations

63
Motor Errors
 Exhausting the eye-hand coordination and
motor skills
 Uncomfortable motor movements
 Highly similar motor sequences
 e.g., double click, click
 Pressure for speed
 Require a high degree of hand-eye coordination
 Requiring special types of motor skills (type)

64
Slips
 Automatic (subconscious) error that occurs
without deliberation
 Examples?
Confirm deletion of file

instead of cancel
65
Types of Slips (1)

1. Capture error - Continue frequently done activity
instead of intended one (similar starts)
 Type “animation” instead of animate
 Confirm deletion of file instead of cancel
2. Description error - Intended action has much in
common with others possible (usually when
distracted, close proximity)
 ctrl key & caps lock key

66
Types of Slips (2)

3. Data driven error - Triggered by arrival of
sensory info which intrudes into normal action
 Call to give someone a number, dial that number
instead
4. Associative activation - Internal thoughts and
associations trigger action
 Phone rings, yell “come in”

67
Types of Slips (3)

5. Loss of activation - Forgetting goal in
middle of sequence of actions
 Start going into room, then forget why you‟re
going there
6. Mode errors - Do action in one mode
thinking you‟re in another
 Delete file, but you‟re in wrong directory

68
Error Prevention Guidelines (1)

 Eliminate modes or provide visible cues for modes
 Use good coding techniques (color, style)
 Maximize recognition, minimize recall
 Design non-similar motor sequences or commands
 Minimize need for typing
 Test and monitor for errors and engineer them out
 Allow reconsideration of action by user (e.g.,
removing file from trash)
69
Error Recovery Guidelines (1)

 Provide appropriate type of response
 Restrain - Prevent user from continuing
 Erroneous login
 Warn - Warn user an unusual situation is
occurring
 Bell or alert box
 Nothing - Just don‟t do anything (Careful, user
must determine problem)
 Not deleting the file without saying why.

70

 Responses
 Self-correct - Guess correct action & do it
 Spell-check correction
 Dialog - System opens dialog with user
 Go into debugger on run-time crash
 Query - Ask user what should‟ve been
done, then allow error action as legal one
 Command language naming error

71

 Provide undo function
 Provide cancel function from operations in
progress
 Require confirmation for drastic, destructive
commands
 Provide reasonableness checks on input data
 Did you really mean to order 5000?

72

 Return cursor to error field, allow fix
 Provide some intelligence
 Guess what they wanted to do
 Provide quick access to context-sensitive
help

Help and Documentation
74
User Support
 Help
 Problem-oriented and specific
 Documentation
 System-oriented and general

75
Help & Documentation

 Never a replacement for bad design, but
essential
 Simple system
 User walks up and uses it
 Using a basic telephone.
 Most other systems with rich features
require help

76
Documentation
 Many users don‟t read manuals
 Boring, no goal
 Just dive in and start working
 Often used in panic mode,
when user needs immediate help
 Manuals probably locked away somewhere
 Points to need for on-line help with search
 Sometimes want quick reference
77
User Support Requirements (1)

 Availability
 Should be available any time the user is
operating the system
 Accuracy & Completeness
 Should be accurate (tricky with changing
versions) and should cover all aspects of
application

78

 Consistency
 Across different sections, between on-line and
paper documentation, in terminology, content
and style
 Robustness
 Should be predictable and free of errors

79

 Flexibility
 Appropriate for novices through experts, maybe
by having expandable sections of details
 Unobtrusiveness
 Shouldn‟t distract from or interfere with normal
work flow

80
Types of Doc/Help (1/4)

1. Tutorial
 For start-up
 Gets user going
 Convey conceptual model
 Communicate essential items
 Sometimes see on-line tour or demo

81

2. Quick reference/review
 Reminder or short reference
 Often for syntax
 Can be recall aid for expert
 Can allow novice to see what‟s available

82

3. Reference Manual (Full explanation)
 Detailed command descriptions
 Usually for experts
 Example: Unix on-line manual pages.

83

4. Context-sensitive (task-specific) help
 System provides help on current situation
 Example: the Microsoft Visual C++ when
calling a function.

84
User Support Approaches (1)

 Command assistance
 Specific details on particular command, such as
UNIX man
 Good if user knows what he wants, but that is
not always the case
 Command prompts
 Message when user commits an error

85

 Context-sensitive help
 Knowledge of particular user to information
pertinent to a particular situation or interface
item
 On-line tutorials
 Work through simple examples, provide a feel
for application

86

 On-line documentation
 How much like paper doc?
 Electronic can emphasize hypertext, indexing,
and searching more

87
Medium
 Paper versus monitor
 Studies show that people are 15-30% slower
reading and comprehending text from a
display as compared to paper

88
Monitor
 Causes for slow-down

 Poor fonts (mono-space, bad spacing,…)
 Low contrast of letters & background
 Emitted vs. reflected light
 Small display  page turning
 Distance, placement of monitor
 Layout and formatting problems
 Reduced hand and body motion
89
Presentation Issues (1)

Integrate with system, don‟t “add on”
1. How is help requested?
 Command, button, function, separate
application
2. How is help displayed?
 Separate window, whole screen, part of screen,
on top of application, pop-up box, command
line, highlighted button, light bulb..
 Largely depends on what type of help it is
90
Presentation Issues (2)

3. Effective presentation of help
 Design it like any other part of UI: language,
terminology, jargon, etc.
 Use active voice
 “To close a window, place the mouse cursor in the box at the
upper right corner (with the X) and click the mouse button.”
4. Implementation issues
 Fast response time is important
 How is help stored? File, database, …?

91
Help Levels
1. Designer model
 System designer has model of typical user and builds
interface with this in mind
2. Adaptable help
 User can edit their own model, for example, .profile on
UNIX
3. Adaptive help
 System maintains a user model and can change it on the
fly.
 Tailor help level and style to the particular user

92
Recommendations for Help

 OK  Better
 All details of each  Subsets of concepts
command
 Formal notation  Lots of examples
 short, technical style  Readable explanations
with a minimum of
technical terms

93
Doc Organization (1)

 State educational objectives
 Present concepts in logical sequence,
increasing order of difficulty
 Avoid forward references
 Make sections have roughly equal amounts
of material
 Have plenty of examples, complete sample
sessions
94
Doc Organization (2)

 Each concept section:
 Explain reason for concept
 Describe concept in task-domain semantic
terms
 Show computer-related semantic concepts
 Offer syntax
 Table of contents and index are important
 Keep reading level simple

95
Improving Doc
 Run through think-aloud sessions
 Use on-line example tutorials
 Try to predict common states and problems
 Anticipate errors
 Develop manuals early and pilot test
 Iteratively refine

96
Terminology
 Avoid  Better
 know, think,  process, print,
understand, have compute, sort, store,
memory search, retrieve
 ask, tell, speak to,  use, direct, operate,

communicate with program, control

97
Who do you design for? (1)

 Novices
 Walk up and use systems.
 Interface affords restricted set of tasks.
 Introductory tutorials to more complex uses.
 Casual
 Standard language.
 Recognition (visual affordances) over recall
 Interface affords basic task structure

98
Who do you design for? (2)

 Intermediate
 Advanced language
 Complex controls
 Reminders and tips
 Interface affords advanced tasks
 Expert
 Shortcuts for power use
 Interface affords full task + task customization

99
Why design is hard (1)

 The number of things to control has increased
dramatically
 car radio: AM, FM, 5 pre-sets, station selection,
balance, fader, dolby, tape eject, fast forward and
reverse, etc
 display is increasingly artificial
 feedback more complex, subtle, and less natural
 errors increasing serious and/or costly

100

 Marketplace pressures
 adding functionality (complexity) now easy and
cheap : computers
 adding controls/feedback expensive
 physical buttons on calculator, microwave oven
 design usually requires several iterations before
success
 product pulled if not immediately successful

101
 People consider cost and appearance over design

 bad design not always visible
 people tend to blame themselves when errors occur
 “I was never very good with machines”
 “I knew I should have read the manual!”
Example: the new wave of cheap telephones
 accidentally hangs up when button hit with chin
 trendy designs that are uncomfortable to hold

CSC417 Lecture08

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CSC417 Lecture08

Uploaded by

Copyright:

Available Formats

CSC417: Human Computer Interaction

Lecture 08: Designing and

Dr. Charbel T. Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

The Chariot Race (1)

Lecture 08 - CSC417 © Dr. Charbel Fares

The Chariot Race (2)

- The DRIVER makes an error!!!

Lecture 08 - CSC417 © Dr. Charbel Fares

Human Factors Engineered

Lecture 08 - CSC417 © Dr. Charbel Fares

Example: Tractors (1)

Example: Tractors (2)

Lecture 08 - CSC417 © Dr. Charbel Fares

Example: Tractors (3)

 low center of gravity

 wider wheel bases

Lecture 08 - CSC417 © Dr. Charbel Fares

So what does this teach us?

 Today: Usability sells

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

 Poor choice for novices

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

 Good naming and abbreviations

Lecture 08 - CSC417 © Dr. Charbel Fares

Names and Abbreviations

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

Picking Good Abbreviations

 Predominant interface paradigm now (with

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

Direct Manipulation Essence

 The user is able to apply intellect directly to

Lecture 08 - CSC417 © Dr. Charbel Fares

Direct Manipulation Advantages

Lecture 08 - CSC417 © Dr. Charbel Fares

Direct Manipulation Advantages

Lecture 08 - CSC417 © Dr. Charbel Fares

Direct Manipulation Problems (1)

Lecture 08 - CSC417 © Dr. Charbel Fares

Direct Manipulation Problems (2)

Lecture 08 - CSC417 © Dr. Charbel Fares

3- Speech and Natural Language

Lecture 08 - CSC417 © Dr. Charbel Fares

When to Use Speech

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

 Could also be important for monitoring meetings,

 Improving all the time

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares

Lecture 08 - CSC417 © Dr. Charbel Fares