HCI Lecture Revision

1
HCI Lecture Revision

• Lecture 1
• Introduction to HCI

2
Disciplines Contributing to Human-Computer
Interaction
Computer Science
Cognitive Psychology
Human-Computer Interaction
Graphic Design
Artificial Intelligence
Social Organisational Psychology
Ergonomics and Human Factors
Sociology
3
What is HCI?
CONTEXT
HUMAN
MACHINE
actions
functions
GOALS
4
Central Aim and Approach of HCI
Aim To optimise performance of human and
computer together as a system

• Approach User-Centred
• Users should not have to adapt to the interface
  the interface should be intuitive and natural for
  them to learn and to use.
• Talking to users is not a luxury, its a
  necessity

5
User-Centred Design
Environment
3
Work
2
People
Technology
1
6
Software Quality (ISO 9126)

• Functionality
• Reliability
• Usability
• Efficiency
• Maintainability
• Portability

7
Usability

• Relationship between
• users goals
• required actions
• results
• must be meaningful, not arbitrary

8
Visibility (Norman, 1988, 1992)
User Goals
User Actions
Functions Of the system
Results
Interface Components (controls)
Feedback
9
Affordance (Norman, 1988, 1992)

• Normans defines as,
• .. A technical term that refers to the
  properties of objects what sorts of operations
  and manipulations can be done to a particular
  object
• Perceived affordance what a person thinks an
  object can do

10
Poor interface may cause

• Increased mistakes in data entry and system
  operation
• Inaccessible functionality
• User frustration low productivity and/or under
  utilisation
• System failure because of user rejection

Nearly half of entire software development effort
relates to the user interface. (Myers and Rosson,
1992)
11
HCI Lecture Revision

• Lecture 2
• User Psychology

12
Human Information Processing
External Environment Sensory Registers Perception
Consciousness Short Term Memory Cognitive
Functions Motor Response
Long Term Memory
7
13
The Model Human Processor

• Brain viewed as three interacting subsystems
• Perceptual system
• Cognitive system
• Motor system
• (Card, Moran and Newell, 1983)

5
14
Model Human Processor
Long Term Memory
Working Memory
Visual Sensory register
Perceptual Processor
Cognitive Processor
Motor Processor
eye
Action
15
Short Term Memory

• Working Memory (working storage)
• Temporary storage buffer (20-30 seconds or more
  with rehearsal)
• Symbolically coded information
• Limited capacity - 7 plus or minus 2 chunks
  (Miller, 1956)
• Number of chunks independent of bits/chunk
• Used for storage and decision-making
• Recency effect recent input overwrites previous
  storage

10
16

Long Term Memory

• Semantically based
• Virtually unlimited in size
• Ease of access related to
• frequency of access / refresh
• time since last access
• number and type of associative links
• interference from other information activated by
  same associations

11
17
Other Psychological Observations

• Closure
• User Attitude and Anxiety
• Control - flexibility
• Recognition
• Learnability

18
HCI Lecture Revision

• Lecture 3
• Designing Users Conceptual Model

19
Example - Journey X to Y
ME
YOU
Images, Movie Words Distances Landmarks
Straight, Church, Left, gjtsjti, Bridge,
Railway gahjjrdj, ???, etc.
Straight, Railway, Church, right, bridge, lights,
left, garage, turn, bend, T-junction, school,
etc.
INTERFACE
20
Four Elements

• The actual system of roads, landmarks, junctions,
  etc. of the journey - System Model
• The communicators concept of this system, which
  may take the form of mental images of the roads
  and landmarks, and knowledge about things like
  the distances involved in various stages of the
  journey - Designers Model
• The actual description of the journey - the
  content of the direct communication between the
  designer and the user - System Image
• The model of the journey as formed in the mind of
  the traveller, the user - Users Mental (or
  conceptual) Model

21
System, Conceptual and Mental Models, and System
Image
Conceptual Model
Mental Model
TOOL - Incomplete - Unstable - Unscientific
User
Designer
4
22
Metaphors

• Form the basis of the designers conceptual
  model, and hence system image
• Allow user to infer knowledge from metaphor to
  system
• Suggests possible operations the user might carry
  out
• One application may draw on multiple metaphors
  (composite metaphors)
• If poorly chosen, can confuse or limit
  understanding

8
23
Theory of Affordance
Much of our everyday knowledge resides in the
world, not in the head Don Norman, 1988

• Perceived potential for action of an object
• Property of an object with reference to the
  observer
• No prior experience required
• Information pickup - exploratory activity of
  looking and moving around

13
24
A Good System Image

• Familiar to users
• Matches way they think about domain (subject
  matter of the system)
• Preferably based on a concrete metaphor
• Support and encourage learning by exploration
• Hides technicalities of system model
• Reflects current status - changes are notified
• Supports retention
• Reduces need for training

16
25
HCI Lecture Revision

• Lecture 4
• HCI Guidelines

26
Design Principles,Guidelines and Rules

• Design principles
• Universally applicable high level design goals
• Have evolved from a body of theoretical work and
  practical experience, for example psychological
  theory, experienced designers, Journals Papers,
  Organisation house styles, etc.
• E.g. design for human cognitive limitations

27
Design Principles,Guidelines and Rules (Contd)

• Design guidelines (packaged experience)
• More specific direct design relevance and the
  context where they should be applied
• Drawn from variety of contexts - limited scope of
  applicability
• Can be used as usability checklists

28
Design Principles,Guidelines and Rules (Contd)

• Design Rules
• Highly specific low-level design rules
• Often found in corporate style guides and design
  manuals
• One example is to aim for a maximum of 10 menu
  items per panel
• Principles and guidelines (and even rules) must
  be selectively applied depending on current
  context

29
Freedom of Interpretation
Heuristics

• Open to broad interpretation
• Often unable to take into account context in
  which the task is undertaken,
• but usability must include task-context dependent
  features
• May only be suitable for specific systems and
  users

• Design principles
• Design guidelines
• Design rules

C o n t i n u u m
30
HCI Guidelines

• Consistency
• Compatibility with Users Expectations
• Flexibility and Control
• Explicit Structure
• Continuous and Informative Feedback
• Error Prevention and Correction
• User Documentation and Support
• Visual Clarity

31
HCI Lecture Revision

• Lecture 5
• HCI Lifecycle and Initial Analysis

32
HCI and the Software Lifecycle
Problem statement
Definition
Systems Analysis (inc. user and task analysis)
Analysis
Requirements spec. (inc. usability specs.)
User object modeling
System design spec. (inc. Interface design spec.)
U s e r P a r t i ci p a t i o n
Users conceptual model design / Interaction
style
Design
Interaction design / Presentation design
Prototype (inc. online help)
Evaluation (Analytical, Empirical)
Implementation
33
Balance Among Conceptual, Interaction and
Presentation Design Effort
Detailed design

• Presentation (Look)
• Visual representations
• Aesthetics
• Interaction (Feel)
• Interaction techniques
• Standard menus

10
Design proceeds mainly from the bottom level up
30
60
Metaphors, object attributes, relationships,
behaviours
Conceptual design
34
Roles in a Team for Interactive System Development
User (domain expert)
Team
User interaction developer
User interface software developer
35
Problem StatementA definition of Design
Objectives

• Statement of overall goal of whole system in a
  single phrase or sentence
• Aim show clear understanding of what is needed
• Main assumptions should be separately stated
• Supported activity human activity that proposed
  system will support
• Users who will perform that activity
• Level of support to be provided - system
  usability
• Form of solution to the problem

36
User Analysis

• Expertise level (novice, intermittent, frequent)
• Familiarity with specific hardware and software
• Software with which users are familiar
• Job-related information access needs
• E.g. summary vs detailed
• Skill base e.g. keyboarding
• General educational level
• Organization-specific knowledge and/or experience

37
Definition of Task Analysis

• Describe tasks in terms of
• Goals they achieve
• Steps involved
• Relevant contextual information
• May provide
• Logical task allocation proposals
• Users terminology
• Initial design decisions often made during task
  analysis
• Task analysis becomes task synthesis
• Directly drives design

38
Task Hierarchy Diagramming (THD)

• Hierarchical structure
• Represents normal sequence of tasks/sub-tasks
• Parallelism can be indicated
• Basis for
• User interface design decisions
• Training and documentation materials
• Annotations on contextual info e.g.
• How often the task/sub-task occurs
• How long they take to complete
• Errors that might occur
• Time it takes a user to become proficient in that
  task
• Other relevant information, e.g. forms or tools
  used

39
Develop Set of Icons
Shared Human - Computer Task
Develop Set of Icons
Determine object/action /feature to represent
Make icons
Save, print, etc.
Assess suitability of existing icons
Decide main shape/symbol
Modify pixels
Assess aesthetics/ compatibility with others
Copy existing icon
Cut/paste/ undo
Draw line
View likely icons
Consider style of icons in current system
Compare with other icons
Add shape
Colour, rotate, flip, invert etc.
Retrieve set of icons
Refer to printed material
40
HCI Lecture Revision

• Lecture 6
• Prototyping the User Interface

41
Prototyping

• The Prototyping approach provides continuous
  feedback on the current design situation
• In HCI there will never be fully satisfactory
  design guidelines applicable in all circumstances
• Need not be computer based or have full
  functionality
• Greatly aided by good software tools
• Graphical editors, construction kits, User
  Interface Management Systems (UIMS)
• Prototyping does NOT mean build in haste

42
Merits of Prototyping

• Requirements capture
• Interface and functional requirements
• Reveals problems/prevents gross mistakes
• Allows evaluation and discussion which fosters
  innovative ideas (from designers and users)
• Users enjoy prototyping and feel involved
• Suggests level of user support needed
• Results in better usability
• Economical way of testing designs

43
Types of Prototyping
Software --------- Life -------- Cycle
Exploratory
Throw-it-away prototypes
Experimental
R a p i d
(Unstructured development)
E v o l u t i o n a r y
I n c r e m e n t a l
(Section-at-a-time )
Horizontal
Full
V e r t i c a l
44
Types of Prototyping (Contd)

• Vertical
• Focus on a specific element and simulate in depth
• Horizontal
• Take a broad perspective but with reduced
  functionality at any point
• Full
• Complete functionality, but less performance than
  final system
• High-fidelity/low-fidelity
• (degree of realism)

45
Prototyping on its Own Possible Limitations

• No coherent conceptual model -gt users feel
  system has unpredictable components
• Uneven appreciation of various user groups
• Lack of task analysis -gt lack of breadth of task
  support
• Failure to fully comply with a style guide -gt
  lack of internal and external consistency
• Lack of usability evaluation
• Users involved with prototype development may not
  represent cross-section of users
• Not easy to learn or intuitive for newcomers
• (see Redmond-Pyle and Moore, 1995)

46
HCI Lecture Revision

• Lecture 6b
• Interaction Styles

47
Interaction Styles

• Linguistic
• Command-line interaction
• Text-based natural language
• Key-modal
• Question-and-answer
• Function-key interaction
• Menu-based interaction
• Direct manipulation
• Forms
• Graphical direct manipulation (GUI)

48
HCI Lecture Revision

• Lecture 7
• Screen Layout and Colour

49
Screen Layout and Colour

• Visual Density
• Text Legibility
• Coding ie underline, bold, shadow, etc.
• Chromatic Aberration and desaturating
• Purpose of colour usage ie searching
• Colour recommendations, colour chart

50
HCI Lecture Revision

• Lecture 8
• Icons and Error Management

51
Icons

• Definition
• Advantages and disadvantages
• Factors affecting meaningfulness

52
Icons Definition

• Pictographic symbols - focus on essential
  features
• Represent underlying
• objects
• data structures
• processes
• in a form which corresponds to the real world
• Can be entertaining, clever and visually appealing

53
Error Management

• Impact of errors - performance, attitude
• Categories of errors - mistake, slip
• File and device errors
• Error message design guidelines
• Be Specific
• Positive Tone
• Constructive Guidance
• Appropriate Physical Format

54
Web Error Control

• Minimise typing use menus, radio buttons
• Only essential information
• Clear questions/prompts/instructions e.g.
  non-optional information
• Limit size of text boxes
• Check boxes rather than multiple select menus

55
Web Error Correction

• CLEAR button
• Ability to go back to any field
• Programmed validation e.g. dates, e-mail address
• Display data entered, ask for confirmation

56
HCI Lecture Revision

• Lecture 9
• Usability Specifications

57
Functional and Usability Specifications

• Functional specifications are central to ensuring
  system functionality
• Usability specifications are central to ensuring
  system usability

58
Common Usability Factors

• Speed of operation
• Completion rate
• Error free rate
• Satisfaction rating
• Learnability
• Retainability
• Advanced feature usage

Main software usability measures identified by
IBM
59
Usability Specification Process

• Defining usability through metrics
• Duration metrics
• Count measures
• Proportion completed
• Quality
• Setting and agreeing planned levels of metrics
• Analysing impact of alternative design solutions
• Incorporating user-derived feedback
• Iterating until planned levels are achieved

60
Sample Rows from a Usability Specification Table
for DTP Package
Task Issue Value to be Current Worst Planned
Best Measured Level Acceptable
Target Possible Level Level Leve
l Install- Installation Length of Many 90
mins 30 mins 20 mins ation task per time to
cant
benchmark successfully
install number 1 install Initial Se
t a tab Number of 3 errors 3 errors 2 errors 0
errors Performance errors Initial Delete a
tab Length of 6 secs 6 secs 4 secs 2 sec
Performance time on first
trial First Questionnaire Average score
?? 3 4.2 5 Impression (range 1-5)
61
HCI Lecture Revision

• Lecture 9 and 10
• Usability Evaluation

62
Definition of Evaluation

• Gathering information about usability or
  potential usability of a system
• Evaluation is concerned with gathering data
  about the usability of a design or product by a
  specified group of users for a particular
  activity within a specified environment or work
  context
• Preece, 1994

63
Reasons why Interface Evaluation is Often Omitted
or Poorly Performed

• Designers assume own personal behaviour is
  representative of that of average user
• Implicit, unsupported assumptions about human
  performance
• Acceptance of traditional/standard interface
  design - assume style guides ensure good software
• Postponement of evaluation until a more
  convenient time
• Poor knowledge of evaluation techniques and lack
  of expertise in analysing experiments

64
Formative Evaluation

• Used for forming and reforming the product
• Integral part of development process
• Purpose to support iterative refinement
• Nature structured, but fairly informal
• Average of 3 major design-test-redesign cycles,
  with many minor cycles to check minor changes

The earlier poor design features or errors are
detected, the easier and cheaper they are to
correct
65
Summative Evaluation

• To evaluate summation of development
• Once, after implementation (or nearly so)
• Purpose quality control - product is reviewed to
  check it meets
• Own functional usability specifications
• Prescribed standards, e.g. Health and Safety, ISO
• Nature formal, often involving statistical
  inferences
• Can be costly time-consuming
• Important in field or beta testing

66
How to EvaluateEvaluation Methods
Method Interface User Involvement deve
lopment Analytic Specification No
users Expert Specification or No
users prototype Role playing
only Observational Simulation or Real
users prototype Survey Simulation
or Real users prototype Experimental Norm
ally full Real users prototype
costs
Empirical