Human–Computer

Interaction

Based on Chapter 16 of Bennett, McRobb

and Farmer:
Object Oriented Systems Analysis and
Design Using UML, (2nd Edition), McGraw
Hill, 2002.
03/12/2001 © Bennett, McRobb and Farmer 2002 1
 In This Lecture You Will
Learn:
 The importance of good user interface
design
 What is meant by metaphors in human–
computer interaction
 About different approaches to human–
computer interaction
 How to apply the techniques of
scenario-based design
 How standards and the law affect
interface design
© Bennett, McRobb and Farmer 2002 2
What is the User Interface?
 Users of systems interact with the system
to carry out tasks by:
– reading and interpreting information about
how to use the system
– issuing commands to the system
– entering words and numbers into the system
as data to work with
– reading and interpreting the results
– responding to and correcting errors
 These are secondary tasks, not primary
objectives
© Bennett, McRobb and Farmer 2002 3
 Metaphors
 Terms used figuratively to describe
something but not applied literally
 Two metaphors for human–
computer interaction:
– the dialogue metaphor
– the direct manipulation metaphor

© Bennett, McRobb and Farmer 2002 4

 The Dialogue Metaphor
 Communication between the human
and the computer is a kind of
dialogue
 There is no real conversation, but
messages are passed from the
human to the computer, the
computer responds in some way, and
that prompts the human to respond,
and so on
© Bennett, McRobb and Farmer 2002 5
Schematic Form of Dialogue

prompt
data S
Output status Y
error S
help T
E
control M
Input
data

© Bennett, McRobb and Farmer 2002 6

 Types of Messages in
Dialogue
Output prompt request for user input
data data from application following user
request
status acknowledgment that something has
happened
error processing cannot continue
help additional information to user
Input control user directs which way dialogue will
proceed
data data supplied by user
© Bennett, McRobb and Farmer 2002 7
 Data Status
Prompt

© Bennett, McRobb and Farmer 2002 8

Data
Error

© Bennett, McRobb and Farmer 2002 9

 Help

Control © Bennett, McRobb and Farmer 2002 10

Use Cases and Dialogue
 The use cases for FoodCo may
document the dialogue between
the user and the system

Enter customer
order

Sales
Clerk

© Bennett, McRobb and Farmer 2002 11

 Use Cases for FoodCo
Enter customer
order «include»

Find customer

View customer «include»

order

Sales
Clerk «extend»

Print customer
order

© Bennett, McRobb and Farmer 2002 12

 The Direct Manipulation
Metaphor
 The interface gives the impression
that you are manipulating physical
objects on the screen through the
use of the mouse:
– you drag and drop an icon
– you shrink or expand a window
– you push a button
– you pull down a menu
© Bennett, McRobb and Farmer 2002 13
 Event-driven Interfaces
 Graphical User Interfaces (GUIs) are event-
driven
 The window manager responds to events
and changes the state of objects in the
windowing system
 In a complex interface like a word-
processor, the user can choose from many
actions; the system has to respond
correctly whichever is chosen and maintain
correct state information
© Bennett, McRobb and Farmer 2002 14
 Event-driven Interfaces
 Sometimes modal dialogues are
used—the user can interact with
only the dialogue box until he or
she closes the dialogue window
 Sometimes the user can be
constrained by disabling and
enabling elements of the interface
to limit his or her choice of action
© Bennett, McRobb and Farmer 2002 15
Constraining User
Interaction
First the user
selects a client
Then the user
selects a
campaign

Finally the user

clicks on Check
and the budget
is displayed
© Bennett, McRobb and Farmer 2002 16
 Constraining User
Interaction
 It makes no sense for the user to pick
a campaign if they haven’t already
selected a client, or to click Check if
they haven’t selected a campaign
 In Chapter 17, we explain how to
model the state of the interface using
statechart diagrams to handle this

© Bennett, McRobb and Farmer 2002 17

 Characteristics of
Good Dialogues
 Consistency
– helps users to learn the application
– even better if all applications within an
organization have consistent standards
– for example, F2 always saves data
– company style guides or style guides
from Microsoft and Apple can be
applied

© Bennett, McRobb and Farmer 2002 18

 Characteristics of
Good Dialogues
 Appropriate user support
– Provide error and warning messages
– If the user has gone wrong the dialogue
should help them to set the situation right
– Avoid hidden content on web pages
– Error messages should be informative not
cryptic, and use terms the user will know
– Use warning messages to prevent likely
errors, but don’t overdo it and irritate users

© Bennett, McRobb and Farmer 2002 19

 Characteristics of
Good Dialogues

 Which error message is most helpful?

 Is this a helpful warning?

© Bennett, McRobb and Farmer 2002 20
 Characteristics of
Good Dialogues
 Adequate feedback
– The user expects some response
when they press a key or click a
button
– If they get no response, users tend to
try again or press another key,
sometimes these key presses get
buffered and produce unexpected
results
© Bennett, McRobb and Farmer 2002 21
 Characteristics of
Good Dialogues
 Minimal user input
– Try to design systems so that users do not have
to make unnecessary keypresses or mouse
clicks
 Use codes and abbreviations
 Let users select from a list
 Let users edit incorrect values rather than retype
them
 Provide information that can be derived automatically
 Use defaults
 Use accelerator keys for menus

© Bennett, McRobb and Farmer 2002 22

 Style Guides
 Microsoft and Apple provide
guidelines on design of interfaces
for their platforms
 Large organizations may have
their own style guides
 The FoodCo terminal screen earlier
on reflects the company’s 1980s
guide on screen design for
minicomputer systems
© Bennett, McRobb and Farmer 2002 23
 Approaches to Interface
Design
 Design is influenced by
– nature of the task the user carries out
– type of user
– amount of training user will have
received
– frequency of use
– hardware and software architecture
 Approaches can be informal or formal
© Bennett, McRobb and Farmer 2002 24
© Bennett, McRobb and Farmer 2002 25
 Approaches to Interface
Design
 Formal approaches include
– structured approaches
– ethnographic approaches
– scenario-based approaches
 All carry out three main steps
– requirements gathering
– design of the interface
– interface evaluation
© Bennett, McRobb and Farmer 2002 26
© Bennett, McRobb and Farmer 2002 27
 Structured Approaches
 Relate to structured approaches to
analysis and design prevalent in
1980s and early 1990s
 Model life cycle as stages, steps
and tasks
 Allow for activities to be carried
out in parallel

© Bennett, McRobb and Farmer 2002 28

 Structured Approaches
 Benefits
– Breakdown into stages and steps
makes project management easier
– Provide standards in diagrams and
documentation that improve
communication
– Specification is comprehensive and is
therefore more likely to result in a
good quality system

© Bennett, McRobb and Farmer 2002 29

 Structured Approaches
 Concentrate on understanding tasks
and allocating tasks between the users
and the system
 Make extensive use of checklists to
characterize users, tasks and
environment
 STUDIO (Structured User-interface
Design for Interface Optimisation) is an
example
© Bennett, McRobb and Farmer 2002 30
 STUDIO
 Uses a number of techniques
– task hierarchy diagrams
– knowledge representation grammars
– task allocation charts
– statecharts
 See task hierarchy diagram in next
slide

© Bennett, McRobb and Farmer 2002 31

 Take an Vol: 200 per day
Order E. Time 50 secs.
Errors: Duplicate
customer

Identify Customer Order Confirm

Customer Order No. Content Order
Delivery

Existing New
Order Line Confirm
Customer Customer
Order Total
Code

Get Get Credit *

Customer Reference Products
Details Details

Identify Product Confirm

Product Quantity Line Total

Known Look Up
Product Product By
Code Name

© Bennett, McRobb and Farmer 2002 32

 STUDIO
 Five stages
– Project Proposal and Planning
– User Requirements Analysis
– Task Synthesis
– Usability Engineering
– User Interface Development

© Bennett, McRobb and Farmer 2002 33

 Structured Approaches
 Criticisms
– Tend to be very bureaucratic, with
lots of forms and checklists
– Evaluation of usability under
laboratory conditions (as with
RESPECT) lacks ‘ecological validity’

© Bennett, McRobb and Farmer 2002 34

Ethnographic Approaches
 Rooted in ethnographic approaches in
sociology and anthropology
 Researcher seeks to be involved in
the situation he or she is studying
 Only this way can the situation be
properly understood
 Qualitative rather than quantitative

© Bennett, McRobb and Farmer 2002 35

 Ethnography
‘In its most characteristic form it involves
the ethnographer participating, overtly or
covertly, in people’s daily lives for an
extended period of time, watching what
happens, listening to what is said, asking
questions—in fact, collecting whatever
data are available to throw light on the
issues that are the focus of the research.’
(Hammersley and Atkinson, 1995)

© Bennett, McRobb and Farmer 2002 36

Ethnographic Approaches
 Interface designer needs to be
immersed in the task of the users
 Recognizes that different users
experience the task subjectively
 Criticizes some methods for failing
to address the context of the task
 Structured approaches respond by
adding a ‘contextual analysis’
checklist
© Bennett, McRobb and Farmer 2002 37
 Contextual Enquiry
 One method of ethnographic
analysis
 Developed by John Whiteside at
DEC
 Evaluates usability in normal
working environment

© Bennett, McRobb and Farmer 2002 38

Ethnographic Approaches
 Use a variety of data gathering
techniques, including interviews,
discussions, video-taping users,
prototyping
 Read more on ‘Participative
Design’ in Chapter 22

© Bennett, McRobb and Farmer 2002 39

Scenario-based Approaches
 Less formal than structured approaches
but more formal than ethnography
 Use scenarios as a tool in requirements
gathering, interface design and
interface evaluation
 Scenarios are step-by-step descriptions
of a user’s actions
 Closest of the three approaches to use
case modelling and fits well with it

© Bennett, McRobb and Farmer 2002 40

Scenario-based Approaches
 Scenarios can be
– textual descriptions
– storyboards
– prototypes
– video mock-ups

© Bennett, McRobb and Farmer 2002 41

 Example Scenario
in Existing System
Pete starts up the word-processor.
He types in a title for the note and changes its style to Title.
He types in two paragraphs describing his idea for an advertisement for
the Yellow Partridge campaign to be used in fashion magazines in Europe
during the summer of 1999.
He types his initials and the date and time.
He uses the short-cut keys to save the file.
The save-as dialogue box appears and, using the mouse, he changes to
the Summer 1999 Campaign folder in the Yellow Partridge folder on the
server.
He scrolls to the bottom of the list of files already in the folder and reads
the title of the last note to be added, Note 17, he calls the new note Note
18 and clicks on Save.
He exits from the word-processor.
© Bennett, McRobb and Farmer 2002 42
 Example Scenario
for the New System
The user selects Add a Note from the menu. A new window appears.
From the list box at the top of the window she selects the name of the client.
A list of campaigns appears in the list box below, and she selects a particular
campaign.
A list of adverts appears in the next list box, and she selects a specific advert.
She types a few paragraphs into a text box to describe her idea for the advert.
She fills the space on screen and a vertical scrollbar appears and the text in the
text box scrolls up.
She enters her initials into a text box, and the system checks that she is
allocated to work on that campaign.
The date and time are displayed by the system, and the Save button is enabled.
She clicks on the Save button and the word Saved appears in the status bar.
The text box, the text field for initials and the date and time are cleared.

© Bennett, McRobb and Farmer 2002 43

Scenario-based Approaches
 Can be used (among other things)
to
– gather requirements—describe what
the user does now
– envision solutions—describe possible
ways of working
– evaluate system—write test cases that
follow scenarios
– document the system—write manual
sections that follow scenarios
© Bennett, McRobb and Farmer 2002 44
Scenario-based Approaches
 Scenarios can be worked through with
the users, building prototype solutions
 Scenarios can be used to develop
‘design claims’ (Carroll, 1995), which
justify design decisions in terms of the
scenarios
 If textual scenarios are used, large
volumes of text result and must be
managed carefully
© Bennett, McRobb and Farmer 2002 45
 Design Claims
The Save button is disabled until the user has selected a client and a
campaign, entered some text and entered his or her initials. This
prevents the user attempting to save the note before all data has been
entered and getting an error message.
The initials of the user could be entered automatically from their network
login, but observation shows that the creative staff often work together as
a group and different people will come up with ideas that they record as
notes. It would be inconvenient for them to be logging in and out of the
system each time a different person wants to enter a new note. For this
reason, they are required to enter their initials.
The initials, date, time and text fields are cleared after a note is saved,
but the client, campaign and advert list boxes are left untouched so that
the user can enter another note for the same advert or campaign without
having to reselect these items.
© Bennett, McRobb and Farmer 2002 46
 Achieving Usability
 Usability is not ‘user-friendliness’
 Usability can be measured (Shackel, 1990)
– Learnability—time and effort required to
achieve a particular level of performance
– Throughput—speed with which tasks can be
achieved, number of errors
– Flexibility—ability to respond to changing tasks
and environment
– Attitude—how positive an attitude users have

© Bennett, McRobb and Farmer 2002 47

 Standards and
Legal Requirements
 International standards do not
have force of law
 ISO 9241—standard for ergnomic
requirements for work with Visual
Display Terminals
 ISO 14915—standard for
Multimedia User Interface Design

© Bennett, McRobb and Farmer 2002 48

 Standards and
Legal Requirements
 EU Council Directive of May 1990
 In the UK implemented in law as the
Health and Safety (Display Screen
Equipment) Regulations 1992
 All workstations must comply with
minimum requirements and employers
have a duty in law to ensure the health
and safety of employees using display
screen equipment
© Bennett, McRobb and Farmer 2002 49
 Standards and
Legal Requirements
 Employers are required to:
– analyse risks
– take action to reduce risks
– ensure workstations meet requirements
– plan work activities to include breaks
– provide eyesight tests for users
– provide corrective appliances for eyes
– provide relevant training
– provide information to employees
© Bennett, McRobb and Farmer 2002 50
 Standards and
Legal Requirements
 Software must be suitable for task
 Software must be easy to use and adaptable to
the user’s knowledge and experience
 Employer may not use software to check up on
employees without their knowledge
 Systems must give feedback to users about
performance
 Systems must display information suited to users
 Principles of software ergonomics must be
applied to the way people process data

© Bennett, McRobb and Farmer 2002 51

 Standards and
Legal Requirements
 In Singapore the Ministry of Manpower
published Guidelines for Work with Visual
Display Unit or Visual Display Terminal
(VDT) in 2000
 In Hong Kong the first Regulation to be
considered under the Occupational Safety
and Health Ordinance (OSHO) 1997 was
the Occupational Safety and Health
(Display Screen Equipment) Regulation

© Bennett, McRobb and Farmer 2002 52

 Summary
In this lecture you have learned about:
 The importance of good user interface
design
 What is meant by metaphors in human–
computer interaction
 About different approaches to human–
computer interaction
 How to apply the techniques of scenario-
based design
 How standards and the law affect interface
design
© Bennett, McRobb and Farmer 2002 53
 References
 Shneiderman (1997)
 Browne (1994)
 Whiteside et al. (1988)
 Carroll (1995)
(For full bibliographic details, see
Bennett, McRobb and Farmer)

© Bennett, McRobb and Farmer 2002 54