HCI Notes

HUMAN COMPUTER INTERACTION
SCO307 HUMAN COMPUTER INTERACTION

Course description
The origins and scope of human computer interaction (HCI): Importance of HCI
in the development of usable computer systems; Paradigm shifts. Human factors
in computer systems. Interaction: Cycle; Models; Interaction devices. Interaction
styles. Interaction design: Contextual design; User Centered Design. Interaction
design Process; Prototyping, User analysis, Task analysis, Domain analysis.
Tools support for interaction design. User Support. Evaluation: Approaches,
Techniques. Computer Supported Cooperative work. Universal design. Multi-
modal and Multi-media interfaces. Future directions and challenges for HCI
Prerequisite: SMA191: Introduction to Computer Programming
Course aims
Students will be introduced to the basic foundations of human computer interaction.
Learning outcomes
Upon completion of this course you should be able to;
1. Explain the importance of users in the design and development of
interactive computer systems
2. Describe the techniques and skills required to develop more usable

interactive computer systems.
3. Undertake user interface design for an interactive computing system.
4. Evaluate the usability and functionality of an information system
Instruction methodology
Lectures, Practical’s, Assignments, Tutorials, Demonstrations, case
studies and class presentations.
Instructional Materials/Equipment
LCD projector, Computer laboratory, e-learning materials, Internet
ii
Course Text Books
1. Alan Dix,Janet E. Finlay, Gregory D. Abowd, Russell Beale (2004). Human-
Computer Interaction (3rd. ed.). Prentice Hall. ISBN: 0130461091
2. Laura Leventhal, Julie Barnes (2007). Usability Engineering: Process, Prod-

ucts and Examples. Prentice Hall. ISBN-10: 0131570080
3. Barfield (1993) .The User Interface: Concepts and Design, Addison-Wesley

. ISBN-10: 0201544415 | ISBN-13: 9780201544411
Course Journals
1. Acta Informatica ISSN 0001-5903
2. Advances in Computational Mathematics ISSN 1019-7168
3. Advances in data Analysis and Classification ISSN1 1862-5347 4
4. Annals Of software Engineering ISSN 1022-7091
Reference Textbooks
1. John M. Carroll (2001). Human-Computer Interaction in the New Millen-
nium. Addison Wesley Professional - ACM Press. ISBN: 0201704471
2. Serengul Smith-Atakan (2006). Human Computer Interaction.

Thomson Course Technology. ISBN: 1844804542
3. Shneiderman B (2009). Designing the User Interface: strategies for Effective

Human Computer Interaction. Addison Wesley, ISBN: 0-201-69497-2
Reference Journals
1. Journal of computer science and Technology ISSN 1000-9000
2. Journal of Science and Technology ISSN 1860-4749
3. Central European Journal Of Computer Science ISSN 1896-1533
4. Cluster computing ISSN 1386-7857
iii
Assessment information
The module will be assessed as follows;
• 30% Continuous Assessment (Tests 10%, Assignment 10%, Practical 10%)
• 70% End of Semester Examination.
iv
Contents
1 Introduction to HCI 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 The Goals of HCI . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.1 Why is usability important? . . . . . . . . . . . . . . . . . 2
1.3.2 Factors affecting usability . . . . . . . . . . . . . . . . . . 3
1.4 HCI and its evolution . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Factors in HCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Disciplines contributing to HCI . . . . . . . . . . . . . . . . . . . . 6
2 Human cognition 9
2.1 Cognitive Psychology . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Cognition and Cognitive Frameworks . . . . . . . . . . . . . . . . 9
2.3 Human Information Processing . . . . . . . . . . . . . . . . . . . 10
2.3.1 The Extended Human Information Processing model . . . . 10
2.3.2 The Multi-Store model of memory . . . . . . . . . . . . . . 11
2.3.3 Problems with the Model Human Processor approach . . . . 12
2.3.4 Beyond the Model Human Processor . . . . . . . . . . . . 12
2.4 Computational versus Connectivist Approaches . . . . . . . . . . . 13
2.4.1 Distributed Cognition . . . . . . . . . . . . . . . . . . . . 13
3 Perception and representation 16

3.1 Perception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 The Gestalt Laws of perceptual organization (Constructivist) . . . . 16
3.2.1 Affordances (Ecological) . . . . . . . . . . . . . . . . . . . 17
3.2.2 Affordances in Software . . . . . . . . . . . . . . . . . . . 17
3.2.3 Perceived Affordances in Software . . . . . . . . . . . . . 17
v
CONTENTS CONTENTS
3.2.4 Link affordance in web sites . . . .............. 18

3.2.5 Graphical links . . . . . . . . . . .............. 18
3.3 Influence of theories of perception on HCI .............. 19
3.3.1 Representation . . . . . . . . . . .............. 19
3.3.2 Graphical Coding . . . . . . . . . .............. 19
3.3.3 Colour coding . . . . . . . . . . .............. 20
3.3.4 Colour theory . . . . . . . . . . . .............. 21
4 Attention and memory 24

4.1 Attention . . . . . . . . . . . . . . . . . . .............. 24
4.2 Focussing attention at the interface . . . . .............. 24
4.3 Multitasking and Interruptions . . . . . . .............. 25
4.4 Automatic Processing . . . . . . . . . . . .............. 26
• Memory Constraints . . . . . . . . . . . . . . . . 27
4.5 Levels of Processing Theory . . . . . . . . . . . . . . . . . . . . . 27
4.5.1 Meaningful Interfaces . . . . . . . . . . . . . . . . . . . . . 27
4.5.2 Meaningfulness of Commands . . . . . . . . . . . . . . . . 27
4.5.3 Meaningfulness of Icons . . . . . . . . . . . . . . . . . . . 28
5 Knowledge and Mental Models 31

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Knowledge Representation . . . . . . . . . . . . . . . . . . . . . . 31
5.2.1 Knowledge in the Head vs. Knowledge in the World . . . . 31
5.2.2 Knowledge Organisation – Schemata and Scripts . . . . . . 32
5.2.3 Mental Models . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Structural and Functional models . . . . . . . . . . . . . . . . . . 35
5.3.1 Bridging the Gulfs . . . . . . . . . . . . . . . . . . . . . . 36
5.3.2 Design considerations: . . . . . . . . . . . . . . . . . . . . 37
6 Interface Metaphors 39
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Verbal Metaphors . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2.1 Advance organisers . . . . . . . . . . . . . . . . . . . . . . 40
6.2.2 Virtual Interface Metaphors . . . . . . . . . . . . . . . . . . 40
6.2.3 Using the Star interface . . . . . . . . . . . . . . . . . . . . 40
vi
CONTENTS CONTENTS
6.2.4 Composite metaphors . . . . . . . . . . . . . . ...... 41

6.2.5 Interface metaphors for applications . . . . . . . ...... 41
6.2.6 Metaphors in user interface elements . . . . . . . ...... 43
6.2.7 Pervasive computing . . . . . . . . . . . . . . . ...... 43
7 User Support 46
7.1 Online Help . . . . . . . . . . . . . . . . . . . . . . . . ...... 46
7.2 Training Wheels . . . . . . . . . . . . . . . . . . . . . ...... 47
8 Interaction Design 49
8.1 Interaction Styles . . . . . . . . . . . . . . . . . . . . . ...... 49
8.2 Command . . . . . . . . . . . . . . . . . . . . . . . . . ...... 49
8.3 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . ...... 50
8.3.1 Fitts’ Law . . . . . . . . . . . . . . . . . . . . . ...... 50
8.4 Pie Menus and Mouse Gestures . . . . . . . . . . . . . . ...... 51
8.4.1 Question and answer dialogues . . . . . . . . . . ...... 51
8.4.2 Form-fill . . . . . . . . . . . . . . . . . . . . . ...... 52
8.4.3 Direct Manipulation . . . . . . . . . . . . . . . ...... 52
9 User-Centred Design 55
9.1 Representations for design . . . . . . . . . . . . . . . . ...... 55
9.2 Models for the design of software . . . . . . . . . . . . ...... 55
9.2.1 Waterfall model . . . . . . . . . . . . . . . . . . ...... 55
9.2.2 Spiral model . . . . . . . . . . . . . . . . . . . . ...... 56
9.2.3 The Star Model . . . . . . . . . . . . . . . . . . ...... 57
9.3 User-centred design . . . . . . . . . . . . . . . . . . . . ...... 57
9.3.1 The 1984 OMS – the original user-centred design ...... 58
9.3.2 Principles of user-centred design . . . . . . . . . ...... 58
9.4 Methods for User- Centred Design . . . . . . . . . . . . ...... 59
9.4.1 Soft Systems Methodology . . . . . . . . . . . . ...... 59
9.4.2 Root definitions . . . . . . . . . . . . . . . . . ...... 60
9.4.3 DSDM....................... ...... 61
• Principles of DSDM . . . . . . . . . . ...... 62
9.4.4 DSDM Lifecycle . . . . . . . . . . . . . . . . . ...... 62
9.5 Other methods . . . . . . . . . . . . . . . . . . . . . . . ...... 63
vii
CONTENTS CONTENTS
10 Usability Engineering 66
10.1 Introduction . . . . . . . . . . . . . . . . . ...... .. ..... 66
10.2 The Usability Engineering lifecycle . . . . ...... .. ..... 66
10.3 Task Analysis . . . . . . . . . . . . . . . . ...... .. ..... 67
10.3.1 Hierarchical Task Analysis (HTA) . ...... .. ..... 67
10.3.2 Cognitive Task Analysis and GOMS ...... .. ..... 67
10.4 Usability Specification . . . . . . . . . . . ...... .. ..... 69
10.5 Guidelines and standards . . . . . . . . . . ...... .. ..... 70
10.5.1 Principles and Rules . . . . . . . . ...... .. ..... 70
10.5.2 Where do guidelines come from? . ...... .. ..... 70
10.5.3 Hix and Hartson’s Guidelines . . . ...... .. ..... 72
10.5.4 Nielsen’s Usability Heuristics . . . ...... .. ..... 73
10.6 Accessibility Guidelines for Web Sites . . . ...... .. ..... 76
10.7 Standards . . . . . . . . . . . . . . . . . . ...... .. ..... 77
10.7.1 International standards bodies . . . ...... .. ..... 77
viii
SCO307 Human Computer Interaction
LESSON 1
Introduction to HCI
1.1. Introduction
HCI (human-computer interaction) is the study of how people interact with
computers and to what extent computers are or are not developed for
successful interaction with human beings. A significant number of major
corporations and academic institutions now study HCI. As its name
implies, HCI consists of three parts: the user, the computer itself, and the
ways they work together.
User
By "user", we may mean an individual user, a group of users working
together. An appreciation of the way people’s sensory systems (sight,
hearing, touch) relay in-formation is vital Also, different users form
different conceptions or mental models about their interactions and have
different ways of learning and keeping knowledge. In addition, cultural and
national differences play a part.
Computer
When we talk about the computer, we’re referring to any technology ranging from
desktop computers, to large scale computer systems. For example, if we were dis-
cussing the design of a Website, then the Website itself would be referred to as "the
computer". Devices such as mobile phones or VCRs can also be considered to be
“computers”.
Interaction
There are obvious differences between humans and machines. In spite of these, HCI
attempts to ensure that they both get on with each other and interact successfully. In
order to achieve a usable system, you need to apply what you know about humans
and computers, and consult with likely users throughout the design process. In real
systems, the schedule and the budget are important, and it is vital to find a balance
between what would be ideal for the users and what is feasible in reality.
1.2. The Goals of HCI
The goals of HCI are to produce usable and safe systems, as well as
functional systems. In order to produce computer systems with good
usability, developers must attempt to:
• understand the factors that determine how people use technology
• develop tools and techniques to enable building suitable systems
• achieve efficient, effective, and safe interaction
• put people first
Underlying the whole theme of HCI is the belief that people using a computer system
should come first. Their needs, capabilities and preferences for conducting various
tasks should direct developers in the way that they design systems. People should
not have to change the way that they use a system in order to fit in with it. Instead,
the system should be designed to match their requirements.
1.3. Usability
Usability is one of the key concepts in HCI. It is concerned with making
systems easy to learn and use. A usable system is:
• easy to learn
• easy to remember how to use
• effective to use
• efficient to use
• safe to use
• enjoyable to use
1.3.1. Why is usability important?

Many everyday systems and products seem to be designed with little regard to us-
ability. This leads to frustration, wasted time and errors. This list contains examples
of interactive products: mobile phone, computer, personal organizer, remote control,
soft drink machine, coffee machine, ATM, ticket machine, library information system,
the web, photocopier, watch, printer, stereo, calculator, videogame etc. . . .
How many are actually easy, effortless, and enjoyable to use?
For example, a photocopier might have buttons like these on its control panel.
Imagine that you just put your document into the photocopier and set the photocopier
to
2
make 15 copies, sorted and stapled. Then you push the big button with
the "C" to start making your copies. What do you think will happen?
1. The photocopier makes the copies correctly.
2. The photocopier settings are cleared and no copies are made.
If you selected (b) you are right! The "C" stands for clear, not copy. The
copy button is actually the button on the left with the "line in a diamond"
symbol. This symbol is widely used on photocopiers, but is of little help to
someone who is unfamiliar with this.
1.3.2. Factors affecting usability

The main factors affecting usability are:
• Format of input
• Feedback
• Visibility
• Affordance
The principles of visibility and affordance were identified by HCI pioneer

Donald Norman.
• Visibility is the mapping between a control and its effect. For

example, controls in cars are generally visible – the steering wheel
has just one function, there is good feedback and it is easy to
understand what it does. Mobile phones and VCRs often have poor
visibility – there is little visual mapping between controls and the
users’ goals, and controls can have multiple functions.
• The affordance of an object is the sort of operations and manipulations

that can be done to it. A door affords opening, a chair affords support.
The important factor for design is perceived affordance – what a person
thinks can be done with an object. For example, does the design of a
door suggest that it should be pushed or pulled open?
3
1.4. HCI and its evolution

This section lists some of the key developments and people in the evolution of HCI.
You will look at some of these in more detail during this course.
• Human factors engineering (Frank Gilbreth, post World War 1) –

study of operator’s muscular capabilities and limitations.
• Aircraft cockpits (World War 2) – emphasis switched to perceptual

and decision making capabilities
• Symbiosis (J.C.R. Licklider, 1960’s) - human operator and computer form

two distinct but interdependent systems, augment each other’s capabilities
• Cognitive psychology (Donald Norman and many others, late 1970’s,

early 1980’s) - adapting findings to design of user interfaces
• Development of GUI interface (Xerox, Apple, early 1980’s)
• Field of HCI came into being (mid 1980’s) – key principles of User
Centred Design and Direct Manipulation emerged.
• Development of software design tools (e.g. Visual Basic, late 1980’s,

early 1990’s)
• Usability engineering (Jakob Neilsen, 1990’s) - mainly in industry

rather than academic research.
• Web usability (late 1990’s) – the main focus of HCI research today.
1.5. Factors in HCI

There are a large number of factors which should be considered in the
analysis and design of a system using HCI principles. Many of these
factors interact with each other, making the analysis even more complex.
The main factors are listed in the table below:
• Organisation Factors
– Training, job design, politics, roles, work organisation
4
• Environmental Factors
– Noise, heating, lighting, ventilation
• Health and Safety Factors
– The User Cognitive processes and capabilities

– Motivation, enjoyment, satisfaction, personality, experience
• Comfort Factors
– Seating, equipment, layout.
• User Interface
– Input devices, output devices, dialogue structures, use of colour,

icons, commands, navigation, graphics, natural language, user
support, multi-media,
• Task Factors
– Easy, complex, novel, task allocation, monitoring, skills
• Constraints
– Cost, timescales, budgets, staff, equipment, buildings
• System Functionality
– Hardware, software, application
• Productivity Factors
– Increase output, increase quality, decrease costs, decrease

errors, in-crease innovation
5
1.6. Disciplines contributing to HCI

The field of HCI covers a wide range of topics, and its development has
relied on contributions from many disciplines. Some of the main disciplines
which have contributed to HCI are:
• Computer Science and technology
– software design, development & maintenance

– User Interface Management Systems (UIMS) & User Interface
Devel-opment Environments (UIDE)
– prototyping tools
– graphics
• Cognitive Psychology and information processing
– capabilities
– limitations
– cooperative working
– performance prediction
• Social Psychology and social & organizational structures
• Ergonomics/Human Factors
– hardware design
– display readability
• Linguistics
– natural language interfaces
• Artificial Intelligence
– intelligent software
• Philosophy, Sociology & Anthropology
6
– Computer supported cooperative work (CSCW)
• Engineering & Design o graphic design
– engineering principles
7
Revision Questions
Example . Suggest some ways in which the design of the copier buttons
could be improved.
Solution: ...
EXERCISE 1. Consider factors involved in the design of a new library

catalogue system using HCI principles..
Further Reading
• Human Computer Interaction by Jenny Preece (Addison Wesley 1994)
8
LESSON 2
Human cognition
2.1. Cognitive Psychology

The science of psychology has been very influential in Human Computer
Interaction. In this course we will look at some of the main developments
and theories in cognitive psychology (the study of human perception,
attention, memory and knowledge), and the ways in which these have
been applied in the design of computer interfaces.
2.2. Cognition and Cognitive Frameworks

Cognition is the process by which we gain knowledge. The processes
which con-tribute to cognition include:
• understanding
• remembering
• reasoning
• attending
• being aware
• acquiring skills
• creating new ideas
A key aim of HCI is to understand how humans interact with computers,

and to represent how knowledge is passed between the two. The basis for
this aspect of HCI is the science of cognitive psychology. The results of
work of cognitive psychologists provide many lessons which can be
applied in the design of computer interfaces. These results are expressed
in the form of cognitive frameworks. This section describes some of the
important frameworks which have been developed by psychologists.
9
2.3. Human Information Processing

HCI is fundamentally an information-processing task. The human information
processing approach is based on the idea that human performance, from
displayed information to a response, is a function of several processing
stages. The nature of these stages, how they are arranged, and the factors
that influence how quickly and accurately a particular stage operates, can be
discovered through appropriate re-search methods. Human information
processing analyses are used in HCI in several ways.
• basic facts and theories about information-processing capabilities

are taken into consideration when designing interfaces and tasks
• information-processing methods are used in HCI to conduct

empirical studies evaluating the cognitive requirements of various
tasks in which a human uses a computer
• computational models developed in HCI are intended to characterize

the in-formation processing of a user interacting with a computer, and to
predict, or model, human performance with alternative interfaces.
The idea of human information processing is that information enters and

exits the human mind through a series of ordered stages (Lindsay &
Norman, 1977), as shown in the figure:
2.3.1. The Extended Human Information Processing model

The basic information processing model shown above does not account
for the importance of:
• attention the processing only takes place when the human is

focussed on the task
• memory the information may be stored in memory and information

already in memory may be used in processing the input
The figure below illustrates the extended human information processing model
(Barber 1988). It shows that attention and memory interact with all the stages of
processing an important question when researching into memory is how it is
10
structured. Memory can be broadly categorised into three parts, which

have links between them, moving the information which comes in through
the senses. Encoding Comparison Response execution Input or stimuli
Output or response Stage 1 Stage 2 Stage 3 Stage 4
Response
selection
Encoding Comparison Response
execution Input or stimuli Output or response Response selection
Attention
Memory
2.3.2. The Multi-Store model of memory

In 1968, Atkinson and Shiffrin developed a model of memory formed of
three ’buffers’, which will store memories and control processes which
move informa-tion between the buffers. The three stores identified are:
• sensory information store
• short-term memory (more recently known as working memory)
• long-term memory
The Model Human Processor

An important concept from cognitive psychology is the model human processor
(MHP) (Card, Moran, and Newell, 1983). This describes the cognitive process that
people go through between perception and action. It is important to the study of HCI
because cognitive processing can have a significant effect on performance, including
task completion time, number of errors, and ease of use. This model was based on
the human information processing model. The model human processor consists of
three interacting systems. Each has its own memory and processor.
• perceptual processor
– outputs into audio storage

– outputs into visual storage
• cognitive processor
11
– outputs into working memory. has access to:
* working memory
* long term memory
• motor processor
– carries out actions
The MHP model was used as the basis for the GOMS family of techniques proposed
by Card, Moran, and Newell (1983), for quantitatively modeling and describing
human task performance. GOMS stands for Goals, Operators, Methods, and
Selection Rules.
Short-term memory store
Long-term memory store
Sensory store
Lost from sensory
store
External
input
2.3.3. Problems with the Model Human Processor approach

• It models performance as a series of processing steps
– is that appropriate?
• It is too focused on one person, one task
• It is an overly simplistic view of human behavior
– ignores environment & other people
2.3.4. Beyond the Model Human Processor

More recent research in cognitive frameworks has focussed on:
• How knowledge is represented
• How mental models are used in HCI
12
• How users learn and become experienced on systems
• How interface metaphors help to match user’s expectations (and

how they don’t!)
• How a person’s mentally-held conceptual model affects behaviour
This represents a change in emphasis from human factors to human actors - a

change in focus on humans from being: passive and depersonalized to active and
controlling. The person is considered as an autonomous agent able to coordinate
and regulate behavior, not a passive element in a human machine system.
2.4. Computational versus Connectivist Approaches

Cognitive theories are classed as either computational or connectionist.
The computational approach uses the computer as a metaphor for how the
brain works, similar to the information processing models described above.
The connectionist approach rejects the computer metaphor in favour of the brain
metaphor, in which cognition is represent by neural networks. Cognitive processes
are characterized as activation of nodes and connections between them.
2.4.1. Distributed Cognition

Distributed cognition is a framework proposed by Hutchins (1991). Its
basis is that to explain human behavior you have to look beyond the
individual human and the individual task. The functional system is a
collection of actors, technology, setting and the interrelations to one
another. Examples of functional systems which have been studied include:
• ship navigation
• air traffic control
• computer programming teams The technique is used to analyze

coordination of components in the functional system. It looks at
• information and how it propagates through the system
13
• how it transforms between the different representational states found in

the functional system One property of distributed cognition that is often
dis-covered through analysis is situation awareness (Norman, 1993)
which is the silent and inter-subjective communication that is shared
among a group. When a team is working closely together the members
will monitor each other to keep abreast of what each member is doing.
This monitoring is not explicit - rather the team members monitor each
other through glancing and inadvertent overhearing The two main
concerns of distributed cognition are:
• To map out how the different representational states are coordinated

across time, location and objects
• To analyze and explain breakdowns
14
Revision Questions
Example . Define cognition
Example . What is the importance of this study in HCI
15
LESSON 3
Perception and representation
3.1. Perception
An understanding of the way humans perceive visual information is
important in the design of visual displays in computer systems. Several
competing theories have been proposed to explain the way we see. These
can be split into two classes: constructivist and ecological.
Constructivist theorists believe that seeing is an active process in which our view is
constructed from both information in the environment and from previously stored
knowledge. Perception involves the intervention of representations and memories.
What we see is not a replica or copy; rather a model that is constructed by the visual
system through transforming, enhancing, distorting and discarding information.
Ecological theorists believe that perception is a process of ‘picking up”
infor-mation from the environment, with no construction or elaboration
needed. Users intentionally engage in activities that cause the necessary
information to become apparent. We explore objects in the environment.
3.2. The Gestalt Laws of perceptual organization (Constructivist)

Gestalt psychology is a movement in experimental psychology that began just prior
to World War I. It made important contributions to the study of visual perception and
problem solving. The Gestalt approach emphasizes that we perceive objects as well-
organized patterns rather than separate component parts. The Gestalt psychologists
were constructivists. The focal point of Gestalt theory is the idea of "grouping," or
how we tend to interpret a visual field or problem in a certain way. The main factors
that determine grouping are:
proximity - how elements tend to be grouped together depending on their closeness.
similarity - how items that are similar in some way tend to be grouped together.
Similarity can be shape, colour, etc.
closure - how items are grouped together if they tend to complete a pattern.
BSc Applied Computing Human Computer Interaction: 3. Perception and
Representation
good continuation - we tend to assign objects to an entity that is defined by smooth
lines or curves. Example in user interface design – proximity used to give structure
16
in a form:
3.2.1. Affordances (Ecological)

The ecological approach argues that perception is a direct process, in which infor-
mation is simply detected rather than being constructed (Gibson, 1979). A central
concept of the ecological approach is the idea of affordance (Norman, 1988). The
possible behaviour of a system is the behaviour afforded by the system. A door af-
fords opening, for example. A vertical scrollbar in a graphical user interface affords
movement up or down. The affordance is a visual clue that suggests that an action is
possible. When the affordance of an object is perceptually obvious, it is easy to know
how to interact with it. Norman’s first and ongoing example is that of a door. Some
doors are difficult to see if they should be pushed or pulled. Other doors are obvious.
The same is true of ring controls on a cooker. How do you turn on the right rear ring?
"When simple things need labels or instructions, the design is bad."
3.2.2. Affordances in Software

Look at these two possible designs for a vertical scroll bar. Both scrollbars
afford movement up or down.
What visual clues in design on the right make this affordance obvious?
3.2.3. Perceived Affordances in Software

The following list suggests the actions afforded by common user interface controls:
• Buttons are to push.
• Scroll bars are to scroll.
• Checkboxes are to check.
• List boxes are to select from. etc.
In some of these cases the affordances of GUI objects rely on prior knowledge or
learning. We have learned that something that looks like a button on the screen is for
clicking. A text box is for writing in, etc. For example, saying that a button on a
screen affords clicking, whereas the rest of the screen does not, is inaccurate. You
could actually click anywhere on the screen. We have learned that clicking on a
button shaped area of the screen results in an action being taken.
17
3.2.4. Link affordance in web sites

It is important for web sites users to know what objects on the page can be clicked
to follow links. This is known as link affordance. The following lists give some
guidelines for improving link affordance:
Text links
• Do use blue underlined text for most links
• Do use underlined headers as links
• Do use words in a left-justified list as individual links
• Do use bullets, arrows or some other indicator in front of certain text links
• Do use "mouse-overs" appropriately and with care
• Do use page location to help communicate that an item is clickable
– Left or right margins

– Top or bottom of the page
• Do use the term "click here" when appropriate
3.2.5. Graphical links

• Do use meaningful words inside graphical links
– Target locations (Home, Back to Top, Next

– Common actions (Go, Login, Submit, Register)
• Do use graphical "tabs" that look like real-world tabs
• Do use graphical buttons that look like real-world pushbuttons
• Do use clear, descriptive labels inside tabs and pushbuttons
• Do make all company logos clickable (to the home page)
18
3.3. Influence of theories of perception on HCI

The constructivist and ecological theorists fundamentally disagree on the
nature of perception. However, interface and web designers should
recognise that both theories can be useful in the design of interfaces.:
• the Gestalt laws can help in laying out interface components to make
use of the context and prior knowledge of the user
• paying careful attention to the affordances of objects ensures that the

infor-mation required to use them can easily be detected by the user.
3.3.1. Representation
A graphical user interface must represent information visually in a way
which is meaningful to the user. The representations may be highly
sophisticated, for ex-ample 3-dimensional simulated ‘walkthroughs’. To
represent 3D objects on a 2D surface, perceptual depth cues are used:
• size
• interposition
• contrast, clarity and brightness
• shadow
• texture
• motion parallax
3.3.2. Graphical Coding

Visual representations can also be used as a form of coding of information at the
user interface. System processes, data objects and other features can be
represented by different forms of graphical coding. Some codings are abstract,
where there is no relation, other than established convention, for example:
• Abstract codes to represent files
• Abstract shapes to represent different objects
19
• Reverse video to represent status
• Colour to represent different options
Other codings are more direct, for example:
• Different icon sizes to reflect different file sizes
• Different line widths to represent different tool widths in a drawing package
• Bar charts to show trends in numerical data
The most direct codings are icons which represent the objects they
portray, for example:
• The wastebin icon
• A paper file to represent a file.
3.3.3. Colour coding

Use of colour improves effectiveness of
• recognition process;
• detection of patterns;
• search (scanning); Usage:
• segmentation: color is a powerful way of dividing a display into separate

regions. Areas/items belonging to each other should have the same color
(note that this is also related to the Gestalt law of similarity);
• amount of color: too many will increase search time – colour pollution;
• task demands: most powerful in search tasks less powerful in tasks

requiring categorization/memorization;
• experience of users: more valuable to novice than to experts;
20
3.3.4. Colour theory

Coloured screens are the primary sensory stimulus that software produces, and
poor colour choices can significantly reduce the usability of GUI applications or
web sites. Colour can affect readability and recognition as described above, and
it can also affect the user’s overall impression of an interface. An application
which uses clashing or discordant colours will often provoke a negative reaction
in users, who will not enjoy using it. Good use of colour can be powerful in any
application, but is particularly important in web pages. Choice of harmonious
colours can be helped by a basic understanding of colour theory. The main tool
for working with colours is the simple colour wheel shown here. (You are best to
look at these notes online to see them in colour!) The black triangle in the centre
points out the primary colours. If you mix two primary colours, you will get the
secondary colour that’s pointed out by the lighter grey triangle. When you mix a
primary with either of its closest secondary colours, you get a tertiary colour;
these are located between the points of the black and grey triangles. A
harmonious set of colours for an interface is known as a colour scheme. Colour
schemes are based on the colour wheel. There are three main sets of colour
schemes: analogous, complimentary, and monochromatic. These are illustrated
using an application called ColorWheel Pro, which is designed to allow colour
schemes to be created and previewed. Each scheme is illustrated by a colour
wheel showing the range of selected colours, and the scheme applied to a logo.
Analogous
Analogous colours are those that are adjacent to each other on the colour
wheel. If you pick any range of colours between two points of either
triangle on our colour wheel (i.e. yellow to red, orange to violet, red to
blue, etc), you will have an analo-gous colour scheme
Complementary
Complementary colour schemes consist of colours that are located opposite each
other on the colour wheel, such as green and red, yellow and violet, or orange and
blue. These colours are said to complement one another. When placed next to each
other, a phenomenon known as simultaneous contrast occurs, wherein each colour
makes the other look more vibrant. There are two pitfalls possible problems
21
with complimentary schemes: • If you place complementary colors on top of one

another, this creates an illusion of movement. This is particularly bad for text. •
Colours like cyan and red, which are not quite directly across from each other,
yet are not close enough to be analogous, will clash rather than complement.
These colors are known as discordants. Complementary colour schemes are
often more complex than simply using two colours from opposite sides of the
colour wheel. For example, a split complimentary scheme is one in which a
colour is paired with the two colours adjacent to its compliment.
Monochromatic
If you mix white with a pure colour, you produce tints of that colour. If you mix black
with a pure colour, you get shades of that colour. If you create an image using only
the tints and shades of one colour you have a monochromatic colour scheme.
22
Revision Questions
Example . ...
Solution: ...
EXERCISE 2. ....
23
LESSON 4
Attention and memory
4.1. Attention
The human brain is limited in capacity. It is important to design user
interfaces which take into account the attention and memory constraints of
the users. This means that we should design meaningful and memorable
interfaces. Interfaces should be structured to be attention-grabbing and
require minimal effort to learn and remember. The user should be able to
deal with information and not get over-loaded.
Our ability to attend to one event from what seems like a mass of
competing stimuli has been described psychologically as focussed
attention. The "cocktail party effect" – the ability to focus one’s listening
attention on a single talker among a cacophony of conversations and
background noise—has been recognized for some time.
We know from psychology that attention can be focussed on one stream of
in-formation (e.g. what someone is saying) or divided (e.g. focussed both on
what someone is saying and what someone else is doing). We also know that
attention can be voluntary (we are in an attentive state already) or involuntary
(attention is grabbed). Careful consideration of these different states of
attention can help de-signers to identify situations where a user’s attention
may be overstretched, and therefore needs extra prompts or error protection,
and to devise appropriate atten-tion attracting techniques.
Sensory processes, vision in particular, are disproportionately sensitive to
change and movement in the environment. Interface designers can exploit
this by, say, re-lying on animation of an otherwise unobtrusive icon to
indicate an attention-worthy event.
4.2. Focussing attention at the interface

Techniques which can be used to guide the user’s attention include:
• Structure – grouping, based on the Gestalt laws
• Spatial and temporal cues – where things are positioned or when they appear
24
• Colour coding, as described in the previous chapter
• Alerting techniques, including animation or sound
Important information should be displayed in a prominent place to catch the user’s

eye Less important information can be relegated to the background in specific areas
– the user should know where to look Information not often requested
should not be on the screen, but should be accessible when needed Note
that the concepts of attention and perception are closely related.
4.3. Multitasking and Interruptions

In a work environment using computers, people are often subject to being inter-
rupted, for example by a message or email arriving. In addition, it is common for
people to be multitasking - carrying out a number of tasks during the same period
of time by alternating between them. This is much more common than performing
and completing tasks one after another. In complex environments, users may be
per-forming one primary task which is the most important at that time, and also
one or more less important secondary tasks. For example, a pilot’s tasks include
attending to air traffic control communications, monitoring flight instruments,
dealing with system malfunctions which may arise, and so on. At any time, one of
these will be the primary task, which is said to be foregrounded, while other
activities are mo-mentarily suspended. People are in general good at
multitasking but are often prone to distraction. On returning to an activity, they
may have forgotten where they left off. People often develop their own strategies,
to help them remember what actions they need to perform when they return to an
activity. Such external representations, or cognitive aids (Norman, 1992), may
include writing lists or notes, or even tying a knot in a handkerchief.
Cognitive aids have applications in HCI, where the system can be design
to pro-vided them –
• the system should inform user where he was
• the system should remind user of common tasks
For example, Amazon’s check out procedure displays a list of steps

involved in the process, and indicates what step has been reached.
25
4.4. Automatic Processing

Many activities are repeated so often that they become automatic – we do
them without any need to think. Examples include riding a bike, writing,
typing, and so on. Automatic cognitive processes are:
• fast
• demanding minimal attention
• unavailable to consciousness
The classic example used to illustrate the nature of an automatic operation

is the Stroop effect. To experiment with this, look at the colour sheet at the
end of this chapter. This experiment demonstrates interference. The
interference between the different information (what the words say and the
colour of the words) your brain receives causes a problem.
There are two theories that may explain the Stroop effect:
• Speed of Processing Theory: the interference occurs because words

are read faster than colors are named.
• Selective Attention Theory: the interference occurs because naming

colors requires more attention than reading words.
If a process is not automatic, it is known as a controlled process.
• Automatic processes
– are not affected by limited capacity of brain

– do not require attention
– are difficult to change once they have been learned
• Controlled Processes
– are non-automatic processes

– have limited capacity
– require attention and conscious control (Shiffrin & Shneider, 1977)
26
Memory Constraints
The human memory system is very versatile, but it is by no means infallible. We find
some things easy to remember, while other things can be difficult to remember. The
same is true when we try to remember how to interact with a computer system.
Some operations are simple to remember while others take a long time to learn and
are quickly forgotten. An understanding of human memory can be helpful in
designing interfaces that people will find easy to remember how to use.
4.5. Levels of Processing Theory

The extent to which things can be remembered depends on its meaningfulness.
In psychology, the levels of processing theory (Craik and Lockhart , 1972) has
been developed to account for this. This says that information can be processed
at different levels, from a shallow analysis of a stimulus (for example the sound of
a word) to a deep or semantic analysis. The meaningfulness of an item
determines the depth of the processing – the more meaningful an item the
deeper the level of processing and the more likely it is to be remembered.
4.5.1. Meaningful Interfaces

This suggests that computer interfaces should be designed to be
meaningful. This applies both to interfaces which use commands and
interfaces which use icons or graphical representations for actions. In
either case, the factors which determine the meaningfulness are:
• Context in which the command or icon is used
• The task it is being used for
• The form of the representation
• The underlying concept
4.5.2. Meaningfulness of Commands

The following guidelines are examples taken from a larger set which was
compiled to suggest how to ensure that commands are meaningful (Booth
1994, Helander, 1988):
27
• Syntax and commands should be kept simple and natural
• The number of commands in a system should be limited and in a

limited format
• Consider the user context and knowledge when choosing command names.
• Choose meaningful command names. Words familiar to the user
• The system should recognize synonymous and alternative forms of

command syntax
• Allow the users to create their own names for commands
Sometimes a command name may be a word familiar to the user in a different

context. For example, the word ‘CUT’ to a computer novice will mean to sever
with a sharp instrument, rather than to remove from a document and store for
future use. This can make the CUT command initially confusing.
4.5.3. Meaningfulness of Icons

Icons can be used for a wide range of functions in interfaces, for example
• Labeling e.g. toolbar item, web page link
• Warning e.g. error message
• Identifying e.g. file types, applications
• Manipulating e.g. tools for drawing, zooming
• Container e.g. wastebasket, folder
The extent to which the meaning of an icon is understood depends on how

it is represented. Representational form of icons can be classified as
follows: Resemblance icons – depict the underlying concept through an
analogous image. the road sign for "falling rocks" presents a clear
resemblance of the roadside hazard.
this represents the Windows calculator application, and resembles a
calculator Exemplar icons – serve as a typical example
28
a knife and fork used in a public information sign to represent "restaurant ser-
vices". The image shows the most basic attribute of what is done in a
restaurant i.e. eating. this represents Microsoft Outlook – the clock and letter
are examples of the tasks this application does (calendar and email tasks)
Symbolic icons – convey the meaning at a higher level of abstraction the picture
of a wine glass with a fracture conveys the concept of fragility this represents a
connection to the internet – the globe conveys the concept of the internet
Arbitrary icons – bear no relation to the underlying concept the bio-hazard sign
consists of three partially overlaid circles this represents a software design appli-
cation called Enterprise Architect. There is no obvious meaning in the icon to tell
you what task you can do with the application Note that arbitrary icons should not
be regarded as poor designs, even though they must be learned. Such symbols
may be chosen to be as unique and/or compact such as a red no entry sign with
a white horizontal bar, designed to avoid dangerous misinterpretation.
Combination Icons
Icons are often favoured as an alternative to commands. It is common for
users who use a system infrequently to forget commands, while they are less
likely to forget icons once learnt. However, the meaning of icons can
sometimes be confusing, and it is now quite common to use a redundant form
of representation where the icons are displayed together with the command
names. The disadvantage of this approach is that it takes up more screen
space. This can be reduced by using pop-up tool tips to provide the text.
Icons in Web Pages

The use of graphical representation in web pages tends to be quite different
to that in other interfaces. Most user actions (links) are usually represented by
text (although the text may actually be an image). There is often isolated and
specific use of icons and graphical representations for links.
29
Revision Questions
Example . ...
Solution: ...
EXERCISE 3. ....
30
LESSON 5
Knowledge and Mental Models
5.1. Introduction
By discovering what users know about systems and how they reason about how
the systems function, it may be possible to predict learning time, likely errors and
the relative ease with which users can perform their tasks. We can also design
interfaces which support the acquisition of appropriate user mental models.
"In interacting with the environment, with others, and with the artefacts of
tech-nology, people form internal, mental models of themselves and of the
things with which they are interacting. These models provide predictive
and explanatory power for understanding the interaction."
- Donald Norman (1993) Mental models are representations in the mind of real
or imaginary situations. Conceptually, the mind constructs a small scale model of
reality and uses it to reason, to underlie explanations and to anticipate events.
5.2. Knowledge Representation

Knowledge is represented in memory as:
• Analogical representations: picture-like images, e.g. a person’s face
• Propositional representations: language-like statements, e.g. a car

has four wheels
• Connectionist theorists believe that analogical and propositional

representa-tions are complementary, and that we use networks of nodes
where the knowl-edge is contained in the connections between the nodes.
5.2.1. Knowledge in the Head vs. Knowledge in the World

Psychologist and cognitive scientist Donald A. Norman published a book titled The
Psychology of Everyday Things. In it he reviews the factors that affect our ability to
use the items we encounter in our everyday lives. He relates amusing but pointed
stories of people’s attempts to use VCRs, computers, slide projectors, telephones,
refrigerator controls, etc. In his book Norman distinguishes between the elements of
good design for items that are encountered infrequently or used only occasionally
31
and those with which the individual becomes intimately familiar through
constant use. Items encountered infrequently need to be obvious. An
example used by Norman is the common swinging door.
The individual intending to pass through the door needs to know whether to push
the door or pull it. We all have experienced doors where it was not obvious what
to do, or two doors appeared the same, but only one would swing. However,
when a door is well designed, it is obvious whether one is to push or pull.
Norman refers to knowledge of how to use such items as being in the world.
However, when one uses something frequently, efficiency and speed are
important, and the knowledge of how to use it needs to reside in the head.
Most people can relate to the common typewriter or computer keyboard.
When one uses it infre-quently and has never learned to type, the knowledge
of which key produces which character on the screen comes from visually
scanning the keyboard and finding the key with the desired character. The
knowledge comes from the world. However, people who frequently use a
computer learn to touch type, transferring the knowl-edge to the head. Their
efficiency and speed far exceed that of the hunt-and-peck typist.
5.2.2. Knowledge Organisation – Schemata and Scripts

One of the main characteristics of knowledge is that it is highly organised.
We can often retrieve information very rapidly. For example, see how
quickly you can retrieve the answers to the following queries:
• What is the capital of Italy?
• Name a model of car manufactured by Ford.
• How many days are there in a year?
You (probably) answered these very quickly, which suggests that the knowledge is
organised in some way. The connectionist network is one theory for how this organ-
isation happens. Another theory is that knowledge consists of numerous schemata. A
schema is network of general knowledge based on previous experience. It en-ables
us to behave appropriately in different situations. For example, suppose you
overheard the following conversation between two friends:
• A: “Did you order it?”
32
• B: “Yeah, it will be here in about 45 minutes.”
• A: “Oh... Well, I’ve got to leave before then. But save me a couple of
slices, okay?
And a beer or two to wash them down with?”

Do you know what they are talking about? You’re probably pretty sure they are
discussing a pizza they have ordered. But how can you know this? You’ve never
heard this exact conversation, so you’re not recalling it from memory. And none of
the defining qualities of pizza are represented here, except that it is usually served in
slices, which is also true of many other things. Schema theory would suggest that we
understand this because we have activated our schema for pizza (or perhaps our
schema for "ordering pizza for delivery") and used that schema to comprehend this
scenario. A script is a special subcase of a schema which describes a characteristic
scenario of behaviour in a particular setting. Schank and Abelson (1977) described
the following script for eating at a restaurant:
Component Specific action
Entering: Walk into restaurant
Look for table
Decide where to site
Go to table
Sit down
Ordering: Get menu
Look at menu
Choose food
Waiter arrives
Give order to waiter
Wait, talk
Cook prepares food
Eating: Cook gives food to waiter
Waiter gives food to customer
Customer eats
Talk
Leaving: Waiter prints bill
Waiter delivers bill to customer
33
Customer examines bill

Calculate tip
Leave tip
Gather belongings
Pay bill
Leave restaurant
People develop a script by repeatedly carrying out a set of actions for a
given setting. Specific actions are slotted into knowledge components.
Schemata can guide users’ behaviour when interacting with computers.
As they learn to use a system they may develop scripts for specific tasks,
such as creating documents, saving documents, and so on. These scripts
may be useful in guiding behaviour when faced with new systems.
In older computer systems, as illustrated in the figure below, there were
few uni-versally accepted conventions for performing common tasks.
Printing a file in one word processor tended to require a different set of
commands or menu options from another word processor. There is much
more commonality between different appli-cations now – to save a file in
pretty much any Windows application you can go to the File menu which
will be the first one in the menu bar, and select Save or Save as. . . .
However, it is still important for interface designers to concentrate on
ensuring that as far a possible their systems make use of the users’ “How
to use a computer” or “How to use a web site” schemata.
5.2.3. Mental Models

A major criticism of schema-based theories is their inflexibility. We are
also good at coping with situations where our scripts are inappropriate.
We can adapt to predict states and comprehend situations we have never
personally experienced The theory of mental models has been developed
to account for these dynamic aspects of cognitive activity.
Mental models are related to schemata – models are assumed to be
dynamically constructed by activating stored schemata. We construct a
mental model at the time to deal with a particular situation.
The term “mental model” was developed in the 1940’s by Craik, who said:
“If the organism carries a ‘small-scale model’ of external reality and of its own
34
possible actions within its head, it is able to try out various alternatives,
conclude which is the best of them, react to future situations before they
arise, utilise the knowledge of past events in dealing with the present and
future, and in every way react to it in a much fuller, safer and more
competent manner to emergencies which face it.”
A key phrase here is to “try out various alternatives”. When an architect is
designing a building, architect’s models allow alternative design ideas to be
tested without actually constructing a real building. Similarly, a mental model
allows a person to test behaviour or reaction to a situation to be tested before
taking any action. This is called running the mental model. The danger in using
mental models is that a person’s model of a situation may not be accurate.
Example. You want to heat up a room as quickly as possible, so you turn up the
thermostat. Will this work? Users will develop mental models of a computer sys-
tem. It is important for interface designers to ensure that their systems encourage
users to develop an appropriate mental model. The system image (the view of
the system seen by the user) should guide the user’s mental model towards the
de-signer’s conceptual model (the way the designer views the system). If the
users’ mental model of how the system works is not accurate, then they may find
the sys-tem difficult to learn, or ‘unfriendly’.
Example. a Windows user exposed to a Unix environment for the first time.
He has to type a document in the Emacs editor as opposed to Word. The
user makes a typo and without hesitating presses his fingers on the Control
and the Z buttons since these are the keys he always used as a keyboard
shortcut for UNDO command. The user gets frustrated as the Emacs editor
completely disappears from the screen and is back to the Unix prompt with no
error message. The fact that the user has been working on Windows builds a
mental model for the UNDO command in almost all windows programs and
associates this model with the action of pressing CTRL-Z, not knowing that
these actions will cause a completely different action in Unix environment.
5.3. Structural and Functional models

Two main types of mental model were identified in the 1980s:
35
Structural models define facts the user has about how a system works.
Knowledge of how a device or system works can predict the effect of any
possible sequence of actions.
Functional models, also known as task-action mapping models, are
procedural knowledge about how to use the system.
The main advantage of functional models is that they can be constructed from
exist-ing knowledge about a similar domain or system. Structural models can
answer un-expected questions and make predictions, while functional models
are based round a fixed set of tasks. Most of the time users will tend to apply
functional models as they are usually easier to construct.
Example: consider changing gear in a car. Think about how to do it and
how you decide which gear to select. Think about constructing a structural
model to capture the features of how it works. Then do the same with a
functional model. Which model do you find more difficult to construct?
5.3.1. Bridging the Gulfs

Closely related to mental models is the idea of gulfs between the interface
of a system and its users. The figure below shows the cycle of interaction
between a user and a system:
The Gulf of Evaluation is the amount of effort a user must exert to interpret
the physical state of the system and how well their expectations and
intentions have been met.
• Users can bridge this gulf by changing their interpretation of the

system im-age, or changing their mental model of the system.
• Designers can bridge this gulf by changing the system image.
The Gulf of Execution is the difference between the user’s goals and what the sys-
tem allows them to do – it describes how directly their actions can be accomplished.
• Users can bridge this gulf by changing the way they think and carry
out the task toward the way the system requires it to be done
• Designers can bridge this gulf by designing the input characteristics

to match the users’ psychological capabilities.
36
5.3.2. Design considerations:

Systems should be designed to help users form the correct productive
mental mod-els. Common design methods include the following factors:
• Affordance: Clues provided by certain objects properties on how this

object will be used and manipulated.
• Simplicity: Frequently accessed function should be easily accessible.

A sim-ple interface should be simple and transparent enough for the
user to concen-trate on the actual task in hand .
• Familiarity: As mental models are built upon prior knowledge, it’s important
to use this fact in designing a system. Relying on the familiarity of a user
with an old, frequently used system gains user trust and help
accomplishing a large number of tasks. Metaphors in user interface design
are an example of applying the familiarity factor within the system.
• Availability: Since recognition is always better than recall, an efficient inter-

face should always provide cues and visual elements to relieve the user
from the memory load necessary to recall the functionality of the system.
• Flexibility: The user should be able to use any object, in any

sequence, at any time.
• Feedback: Complete and continuous feedback from the system

through the course of action of the user. Fast feedback helps
assessing the correctness of the sequence of actions.
37
Revision Questions
Example . ...
Solution: ...
EXERCISE 4. ....
38
LESSON 6
Interface Metaphors
6.1. Introduction
Metaphors convey an abstract concept in a more familiar and accessible
form. A metaphor is a figure of speech in which an expression is used to refer
to something that it does not literally denote in order to suggest a similarity A
widely quoted example can be found in Shakespeare’s As You Like It:
"All the world’s a stage..."
Metaphors are widely used to make use of users’ existing knowledge
when learning new computer systems.
6.2. Verbal Metaphors

Verbal metaphors are useful tools to help users to understand a new system. For
ex-ample, people using a word processor for the first time consider it similar to a
type-writer. This perceived similarity activates the user’s ‘typewriter’ schema,
allowing them to interpret and predict the behaviour of the word processor, for
example: These links provide basic foundation from which users develop their
mental mod-els. Knowledge about a familiar domain (typewriter) in terms of
elements and their relation to each other is mapped onto elements and their
relations in the unfamiliar domain (computer).
• Elements: keyboard, spacebar, return key
• Relations: hit only one character key at a time, hitting a character key
will result in a letter being displayed on a visible medium
By drawing on prior knowledge a learner can develop an understanding of

the new domain more readily.
Dissimilarities can cause problems for learners. For example, the
backspace key on a typewriter moves the carriage back, while on a word
processor it usually deletes a character. However, as they become aware
of the discrepancies, they can develop a new mental model.
39
6.2.1. Advance organisers

Verbal metaphors provided in advance can aid learning. For example, Foss (1982)
studied the effect of describing a metaphor for a system to new users before they
start learning. This is called an advance organiser. In this case file creation and
storage were explained in terms of a filing cabinet metaphor, and the result was that
these user performed better when they actually used the system.
6.2.2. Virtual Interface Metaphors

Verbal metaphors try to explain the use of a computer system in terms of
some-thing that it resembles. Xerox in the late 1970’s realised the potential of
deliber-ately designing interfaces to be more like the real world. Instead of
using verbal metaphors to help understand the interface, they went further
and designed an inter-face metaphor for the Star system– an interface design
based on a real office. Office objects (paper, folders, filing cabinets, in and
out trays) were represented as icons. The overall organising metaphor on the
screen was the desktop, resembling the top of a real office desk.
The ideas of the Star system evolved first into the Apple Macintosh
interface, which then influenced the Windows interface. We still have
desktops on our PCs and Macs.
• Verbal metaphor – parts of a computer system are like a typewriter
• Interface metaphor – the desktop is like an office desktop, but it also

is the interface
Instead of using a verbal metaphor as a basis from which to develop a mental

model, the interface metaphor is the model that is learned. This tends to lead
to the devel-opment of functional mental models of the system.
6.2.3. Using the Star interface

Files were transformed from abstract entities with name to pictorial representations,
or icons. The pictorial representation would let users know how to interact with them
– for example a file or folder can be opened, or placed in the trash.
The mouse was developed to allow electronic actions to be performed
analogous to physical actions: Physical Electronic
40
• Placing hand on object Clicking
• Picking up an object Selecting
• Moving an object Dragging
6.2.4. Composite metaphors

A problem with the ‘metaphor as model’ approach is the difficulty of introducing
new functionality which does not fit into the interface metaphor. Designers have
got round this by introducing composite metaphors. These allow the desktop
metaphor to include objects which do not exist in the physical office, for example:
• menus
• windows
• scroll bars (these make use of the concept of unrolling a scroll, or

rolled-up document)
It might be assumed that users may have difficulty with composite metaphors.
In general it has been found that people can deal with them rather well and
can develop multiple mental models. Some composite mental models can
cause confusion. For example, on a Macintosh, you can eject a disk by
dragging it to the trash – you retrieve it by throwing it away.
6.2.5. Interface metaphors for applications

The desktop metaphor has been used successfully for operating systems.
However, other metaphors have been developed for specific types of
applications, for exam-ple:
Operating system
• Metaphor: The desktop
• Familiar knowledge: office tasks, files,
documents Data Storage
• Metaphor: Filing system
41
• Familiar knowledge: files, folders, storing files, retrieving
files Spreadsheets
• Metaphor: ledger sheet
• Familiar knowledge: columnar tables, calculations
The Web
• Metaphor: Travel
• Familiar knowledge: going from place to
place Online shopping
• Metaphor: Shopping cart
• Familiar knowledge: adding items,
checking out Graphics packages
• Metaphor: Toolbox
• Familiar knowledge: paint, brushes, pencils,
rubbers Media Players
• Metaphor: Tape/CD player
• Familiar knowledge: play, stop, fast-forward/rewind
buttons Multimedia environments and web sites
• Metaphor: Rooms (each associated with a different task)
• Familiar knowledge: interiors of buildings
42
6.2.6. Metaphors in user interface elements

The examples above show the use of metaphors to assist users to
develop a mental model for an application, or a major part of an
application. Within applications and web pages, metaphors can also be
used for specific interface elements. These help users understand how to
interact with those elements. For example: Tabs
• Metaphor: Card file
Commonly used in web pages and dialogue boxes.

Progress Bars
• Metaphor: progress is to the right (orientational metaphor)
• Based on direction of reading – highly cultural, as some cultures

read from right to left.
Icons
• Symbolic icons use metaphors to convey their meaning – e.g. a globe to

represent the World Wide Web or the magnifying glass icon in a photo
ma-nipulation program to represent zooming in on an image.
6.2.7. Pervasive computing

Pervasive computing, also known as ubiquitous computing. is the trend towards
increasingly ubiquitous connected computing devices in the environment, a trend
being brought about by a convergence of advanced electronic - and particularly,
wireless - technologies and the Internet. Pervasive computing devices are not
per-sonal computers as we tend to think of them, but very tiny - even invisible -
de-vices, either mobile or embedded in almost any type of object imaginable,
including cars, tools, appliances, clothing and various consumer goods - all
communicating through increasingly interconnected networks.
In these devices, the computer interface moves away from the desktop
and the in-terface metaphor is invisible to the user.
The goal of researchers is to create a system that is pervasively and unobtrusively
embedded in the environment, completely connected, intuitive, effortlessly portable,
and constantly available. Among the emerging technologies expected to prevail in
43
the pervasive computing environment of the future are wearable

computers, smart homes and smart buildings.
44
Revision Questions
Example . Discuss the evolution of the desk top. Describe the different
input and output devices, their use and suitability given an application.
Solution: ...
EXERCISE 5. ....
45
LESSON 7
User Support
Users have different requirements for support at different times. User

support should be
• available but unobtrusive
• accurate and robust
• consistent and flexible
User support comes in a number of styles:
• command-based methods
• context-sensitive help
• tutorial help
• on-line documentation (integrated with application)
• written documentation (manuals or notices)
• web-based documentation
Design of user support must take account of
• presentation
• implementation
7.1. Online Help

Many programs come with the instruction manual, or a portion of the manual, in-
tegrated into the program. If you encounter a problem or forget a command while
running the program, you can summon the documentation by pressing a
designated Help key or entering a HELP command Once you summon the Help
system, the program often displays a menu of Help topics. You can choose the
appropriate topic for whatever problem you are currently encountering. The
program will then display a help screen that contains the desired documentation.
46
Some programs are more sophisticated, displaying different Help messages

depend-ing on where you are in the program. Such systems are said to be
context sensitive. There has been a large body of research done to try to
understand how users interact with online help. One aspect which has been
studied is the kind of questions which prompt use of online help (O’Malley
1986, Sellen & Nicol 1990). Typical questions appear to focus on:
• Goal exploration – what can I do with this system?
• Definition and description – what is this? What is it for?
• Task achievement – how do I do this?
• Diagnostic – how did that happen?
• State identification – where am I?
Most desktop applications and operating systems now have

comprehensive online help systems, and a range of tools are avaible to
make the process of creating help systems relatively easy. However, the
system designer must take account of the above question types to make
sure that the system is actually addressing users’ needs.
7.2. Training Wheels

New users of high-function application systems can become frustrated and
confused by the errors they make in the early stages of learning. A training
interface for a commercial word processor (Training Wheels) was designed
by Carroll (1984) to make typical and troublesome error states “unreachable,”
thus eliminating the sources of some new-user learning problems.
Creating a training environment from the basic function of the system itself
afforded substantially faster learning coupled with better learning achievement
and better performance on a comprehension post-test. A control group spent
almost a quarter of their time recovering from the error states that the training
interface blocked off. The principle of allowing access to different levels of
functionality in an application depending on their level of expertise has been used
in a variety of applications since then. However, this approach can lead to
frustration for users when they are told ‘option not available
47
Revision Questions
Example . ...
Solution: ...
EXERCISE 6. ....
48
LESSON 8
Interaction Design
8.1. Interaction Styles

Computers are used to process information. Since the information is needed
by people, people and computers have to interact. Different computer
applications (programs) follow different styles of the interaction, even for the
same operations. The following examples show how you can replace all
occurrences of the word "apple" with the word "orange" in a text file, using:
1. UNIX standard stream text editor "sed"

sed “s/apple/orange/gw new_file” fruits_file $mv New_File Fruits_File
2. MS Word
It is obvious, that the interaction style influences the overall usability of a

program. On the other hand, there are no good or bad interaction styles by
default - each of them could suit a particular user group. Moreover, there are
specific requirements for each interaction style to make it expressive and usable.
8.2. Command
Early applications were command-driven. Users were expert, knowledgeable and
not afraid of computers. They could be expected to overcome any obstacles by
sheer perseverance. Commands provide a way of expressing instructions to the
computer directly. Communication between user and computer is purely textual.
Commands can take the form of function keys, single characters, short
abbreviations, whole words, or combination of the first two.
An issue with command interface is the number of keystrokes required to
complete a command. Commands must be remembered, so care must be
taken in choosing the commands for the system. Command-entry remains
popular in applications where the users are experts and become very
familiar with the commands they can use, for example:
• System administrators, particularly on Unix and Linux systems In the

hands of an expert, command entry can be much more efficient than
any other in-teraction style.
49
8.3. Menus
A list of options is presented to the user and the appropriate decision is
selected by typing some code or selecting the option required. Unlike
command-driven sys-tems, menus do not require the user to remember the
item they want; they only need to recognize it. Menus favour recognition over
recall. This is often described by cognitive psychologists as favouring
‘knowledge in the world’ over ‘knowledge in the head’. The majority of user
interfaces are now designed to make use of knowledge in the world.
Menus are used extensively in GUI systems such as Windows, and are
also widely used to provide navigation systems in web sites. Horizontally
oriented menus in web pages are often referred to as navigation bars.
Menus were used before GUI systems were common. Many DOS
applications used menus, and Windows systems still use non-GUI menus
for start-up options Menus like this can take up a lot of screen space. For
this reason most GUI systems use dropdown menus or pop-up menus.
Web pages often use these types of menu for the same reason.
8.3.1. Fitts’ Law

Fitts’ law is a model of human psychomotor behaviour developed in 1954.
Fitts dis-covered a formal relationship that models speed/accuracy
tradeoffs in rapid, aimed movement (not drawing or writing). Fitts’ Law
calculates the time to move and point to a target of a certain width at a
certain distance. Essentially, Fitts’ Law states that big targets at close
distance are reached faster than small targets at long range. Theoretically,
the following principles exist when applying Fitts’ Law to interface designs:
• Things done more often should be assigned a larger button. This

seems an intuitive principle, but it needs to be used very carefully,
since it harms the consistency of the interface.
• Things done more often should be closer to the average position of

the user’s cursor.
• The top, bottom, and sides of the screen are infinitely targetable because of
the boundary created by the edges of the screen. They should be fully utilized.
50
There are tradeoffs when applying Fitts’ Law to interface designs. Fitts’
Law sug-gests that interface components should be made larger and
positioned closer to the average cursor position. These suggestions may
act in opposition to other factors that make an efficient interface, such as
organization and use of available screen space.
8.4. Pie Menus and Mouse Gestures

Pie menus are a naturally efficient user-interface technique. A pie menu is
a di-rectional selection of pie slice-shaped targets. The cursor starts out in
the inactive centre region of a pie, and all target slices are large, nearby,
and in different di-rections. Pie menus are quite easy for new users. You
simple follow the pop-up directions to use them. They are also extremely
efficient for experienced users. Once you know the directions, you can
quickly and reliably ’mouse ahead’ without looking. Fitts’ Law explains the
pie menu advantage - their fast selection speed and low error rate is due
to their large target size and the small distance between each item
Mouse gestures are mouse movements in combination with a click-hold that
exe-cute some functions. You press mouse button, draw a gesture, and
release mouse button (you can choose which button to use in advanced
preferences). This gesture is recognized and appropriate action is triggered.
Pie menus and mouse gestures extensions to the Mozilla family of web
browsers have been developed under the Optimoz project. Pie menus can be
considered to be essentially mouse gestures with feedback.
8.4.1. Question and answer dialogues

In this kind of interaction questions are asked one at a time and the next question
may depend on the previous answer. Question and answer dialogues are often
used in tasks where information is elecited from users in a prescribed and limited
form, such as a bank ATM. They are now widely used in PC software, in the form
of ‘Wizards’ to guide novice users through tasks. Wizards can be very frustrating
for experienced users who know what they want to do.
51
8.4.2. Form-fill
user type the data in specific fields, similar to the fields on a paper fill-in form.
Many office and database applications use this style. Form-fill is also widely used
in web pages, to obtain feedback or to elicit customer details in transactions.
Some of the issues which should be considered when designing forms include:
• Clarity of layout
• Types of fields – the users should be able to tell what kinds of data
are per-missible in each field.
• Help text (for the form and for each field)
• Automatic advancement (tabbing from field to field) – this can be

very helpful as long as it done in the correct order.
• Cancel option (what does it mean in the situation)
• Corrections – how can the user correct data once entered
• Corresponding paper-form (for example order entry)
• Pre-filled fields – it may save the user time if some fields contain
commonly used initial values
• Use of list boxes to select from predetermined list of optional values.

The spreadsheet is a variation on the form-fill interaction style.
8.4.3. Direct Manipulation

Direct manipulation is a style of interaction which features a natural
representation of task objects and actions promoting the notion of people
performing a task them-selves (directly) not through an intermediary like a
computer. A direct manipulation system has the following features:
• Visibility of the objects of interest
• Rapid, reversible, incremental actions
• Replacement of complex command syntax by direct manipulation of

the ob-ject of interest
52
The visual representation usually takes the form of a metaphor related to

the actual task being performed. Well-designed direct manipulation
systems tend to make the interaction enjoyable for the users.
Shneiderman (1983) believes this owes to factors including the following:
• Novices can learn the basic functionality quickly
• Users can immediately see if their actions are furthering their goals
• Users experience less anxiety because the system is

comprehensible and be-cause actions are reversible
• Users gain confidence because they fell in control and can predict
system responses
Common examples of direct manipulation include:
• File managers, such as Windows Explorer (drag-and-drop copying)
• Graphics software (drawing tools such as Photoshop and Fireworks)
• Games
53
Revision Questions
Example . ...
Solution: ...
EXERCISE 7. ....
54
LESSON 9
User-Centred Design
9.1. Representations for design

In order to develop a system, two major activities are required. The designer
must understand the requirements of the product and must develop the product.
Develop-ment may include producing a variety of representations, or models, of
the system. Representations can be used for a variety of purposes, including:
• Exploring the problem space – sketches, storyboards, paper prototypes
• Communication – models which express ideas to the customer or to

the pro-grammers who will implement the system
• Making predictions – estimation of user performance, project effort and cost
A good representation is accurate enough to reflect the features of the

system, but simple enough to avoid confusion. Representations of
software are equivalent to the various representations used in the design
of a car. What do you think the purposes of the following would be?
• Doodles and sketches
• Blueprints
• Scale models
• Computer model
9.2. Models for the design of software

The following models describe three different methods for the
development of a software system. Each model makes use of a range of
representations and pro-cesses.
9.2.1. Waterfall model

The waterfall model is a software life-cycle model, described by W. W. Royce in
1970, in which development is supposed to proceed linearly through the phases of
55
requirements analysis, design, implementation, testing (validation),

integration and maintenance.
There have been a number of criticisms of the standard waterfall model, including
• There is a ‘contract’ relationship between client and developers – the

user is not involved beyond the initial phase.
• Problems are not discovered until system testing
• Requirements must be fixed before the system is designed, whereas

in reality it is often impossible to understand requirements fully until a
fair amount of design has been undertaken.
• System performance cannot be tested until the system is almost coded The
standard waterfall model is associated with the failure or cancellation of a
number of large systems. It can also be very expensive. As a result, the
soft-ware development community has experimented with a number of
alternative approaches, including the spiral model and the star model.
9.2.2. Spiral model

The spiral model (Boehm, 1988) uses incremental development, with the aim
of managing risk. In the spiral model, developers define and implement
features in order of decreasing priority. An initial version of the system is
developed, and then repetitively modified based on input received from
customer evaluations. The development of each version of the system is
carefully designed using the steps involved in the waterfall model. With each
iteration around the spiral (beginning at the centre and working outward),
progressively more complete versions of the system are built.
The Spiral Model is made up of the following steps:
• Project Objectives. Similar to the system conception phase of the Waterfall

Model. Objectives are determined, possible obstacles are identified and al-
ternative approaches are weighed. • Risk Assessment. Possible alternatives
are examined by the developer, and associated risks/problems are identified.
Resolutions of the risks are evaluated and weighed in the consideration of
project continuation. Sometimes prototyping is used to clarify needs.
56
• Engineering & Production. Detailed requirements are determined

and the software piece is developed.
• Planning and Management. The customer is given an opportunity to ana-

lyze the results of the version created in the Engineering step and to offer
feedback to the developer. The Spiral model relies heavily on prototyping.
When using prototyping, the developer builds a simplified version of the
pro-posed system and presents it to the customer for consideration as part
of the development process. The customer in turn provides feedback to the
devel-oper, who goes back to refine the system requirements to
incorporate the ad-ditional information. Often, the prototype code is thrown
away and entirely new programs are developed once requirements are
identified. We will look at prototyping methods in a later chapter.
9.2.3. The Star Model

The star model (Hartson & Hix, 1989) emphasises that the design of interactive
systems typically does not follow a specific order of steps. Evaluation represents the
central phase in the development cycle. Development can start from any point in the
star (as shown by the entry arrows) and any stage can be followed by any other
stage. Evaluation is always done before moving to a new stage. The requirements,
design and product gradually evolve, becoming increasingly well-defined.
The star model can give the user a significant role throughout the project since
evaluation is central to the cycle. It is particularly oriented towards the development
of interactive systems that will be usable by people. Evaluation can be based on any
representation of the system. A variety of representations may be used during the
development, including sketches, scenarios, prototypes and formal models.
9.3. User-centred design

User centred design is an approach to software development user-centred design
focuses specifically on making products usable. The approach typically entails in-
volving users in the design and testing of the system so that their feedback can be
obtained. Prototypes are usually employed to do this and designs are modified in
light of the user feedback. Initially it may seem that the user-centred approach
complicates the software development task, due to the need to make iterative refine-
57
ments to the software in light of user feedback. However the benefits to be gained
are considerable. The process promotes communication between users, managers
and those developing the software and identifies problematic issues early on in the
development schedule when it is much cheaper to implement changes.
9.3.1. The 1984 OMS – the original user-centred design

The first major user-centred design project was the Olympic Messaging System
(OMS) used at the 1984 Olympics in Los Angeles. OMS was developed in order to
provide a message service (voice mail) and other support for the 10,000 athletes
who attended the 1984 games. Kiosks were placed around the Olympic village An
OMS kiosk After some initial analysis of the requirements for the system, printed
scenarios of the user interface were prepared. These were commented on by de-
signers, management and prospective users. As a result of this early evaluation, a
number of the system functions were altered and others were dropped completely
The design team also produced brief user guides aimed at explaining what the sys-
tem did and how it worked These were tested on the main user groups (Olympians,
their families and friends) and were developed iteratively (over 200 slightly modi-fied
versions were produced) before the final form was decided. Early simulations of the
messaging system were also constructed and evaluated for the purpose of designing
help messages. These simulations were tested with users. One thing that these tests
revealed, for example, was that an ‘undo’ or ‘backup’ key was required so that users
could retrieve a previous position if they made a mistake. Many other methods were
used to collect information about what was needed, including tours of the Olympic
village sites, early demonstrations of the system, interviews with the different people
involved in the Olympics and discussions with an experienced ex-Olympian who was
part of the design team. A prototype was then developed which was tested with
different user groups. This resulted in many more iterations and retesting.
9.3.2. Principles of user-centred design

The key principles of user-centred design were developed from the design of the
OMS (Gould, 1987):
• Focus early in the design process on users and their tasks
58
• Measure users’ reactions and performance to scenarios, manuals,

simulations, and prototype are observed, recorded and analysed
• Design iteratively: when problems are found in user testing, fix them
and carry out more tests
• All usability factors must emerge together and be under the

responsibility of one control group. Gould commented that of 450
system designers and devel-opers who were asked to write down the
steps they recommend in the design of an office system, 26 percent
of them mentioned none of the principles, and another 35 percent
mentioned only one of the principles. Clearly, the princi-ples of user-
centred design were far from being obvious to designers at that time.
9.4. Methods for User- Centred Design

9.4.1. Soft Systems Methodology
Hard problems are problems characterized by the fact that they can be
well defined. You assume that there is a definite solution and you can
define a number of specific goals that must be accomplished. In essence,
with a hard problem you can define what success will look like prior to
embarking on implementing the solution. The "WHAT" and the "HOW" of a
hard problem can be determined early on in the methodology.
Soft problems, on the other hand, are difficult to define. They will have a large
social and political component. When we think of soft problems, we don’t think of
problems but of problem situations. We know that things are not working the way
we want them to and we want to find out why and see if there is anything we can
do about it Soft Systems methodology was developed by Peter Checkland for the
express purpose of dealing with problems of this type.
He had been in industry for a number of years and had been working with a number
of hard system methodologies. He saw how these were inadequate for the purpose
of dealing with extremely complex problems which had a large social component so
in the 1960’s he turned to the University of Lancaster, in the UK, in an attempt to
research this area and deal with these SOFT problems. His "Soft Systems Method-
ology" was created through a number of research projects in industry and its appli-
59
cation and refinement over a number of years. The methodology was

published in 1981. SSM is divided into seven distinct stages. These are;
1. Finding out about the problem situation. This is basic research into
the prob-lem area.
Who are the key players? How does the process work now? etc.
2. Expressing the problem situation through Rich Pictures. As with any

type of diagram, more knowledge can be communicated visually.
3. Selecting how to view the situation and producing root definitions.
4. Building conceptual models of what the system must do for each root
defini-tions. You have basic "Whats" from the root definitions. Now
begin to define "Hows".
5. Comparison of the conceptual models with the real world. Compare the
re-sults from steps 4 and 2 and see where they differ and are similar.
6. Identify feasible and desirable changes. Are there ways of improving

the situation.
7. Recommendations for taking action to improve the problem situation.

How would you implement the changes from step 6.
9.4.2. Root definitions

The CATWOE criteria contain the elements considered when formulating
defini-tions of a desired system. These definitions are called Root
Definitions (RDs), be-cause they describe the root, core or essence of the
human activity to be modelled. Root definitions express the nature of
purposeful human activity systems with a view toward exploring the
problem situation as a basis for change. The CATWOE elements:
• Clients (or customer)
• Actors
• Transformation
60
• Weltanschaunnng (or world view)
• Owners
• Environment
For example, a system is
• : owned by O
• : to do W : by A
• : by means of T : given the constraints of E
• : in order to achieve X : for C.
9.4.3. DSDM
DSDM stands for (Dynamic Systems Development Method). DSDM is a frame-work
for Rapid Development that combines the benefits of prototyping, an iterative
development life cycle, time-boxing and Joint Application Development (JAD). The
method has evolved with input from member organisations of the DSDM consor-tium
(www.dsdm.org), which was launched in 1994, and draws from real project
experience. DSDM has been widely adopted throughout the UK and Europe.
Evolutionary project organisation uses time boxing rather than feature
boxing. With a fixed set of resources it is possible to realise either:
• A fixed set of features in the time needed to realise these features.

We call this feature boxing.
• The amount of features we can realise in a fixed amount of time. We call

this time boxing. DSDM is a suitable process when the system functionality
is to be visible at the user interface, there is access to a well-defined user
group, functionality can be segmented into a number of small, well-defined
deliverables, and the requirements are flexible. It may not be suitable for
computationally-complex or safety-critical systems.
61
Principles of DSDM
1. Active user involvement is imperative.
2. The team must be empowered to make decisions.
3. The focus is on frequent delivery of products.
4. Fitness for business purpose is the essential criterion for acceptance

of deliv-erables.
5. Iterative and incremental development is necessary to converge on

an accu-rate business solution.
6. All changes during development are reversible.
7. Requirements are baselined at a high level.
8. Testing is integrated throughout the life-cycle.
9. Collaboration and cooperation between all stakeholders is essential
9.4.4. DSDM Lifecycle

The Feasibility and Business Study phases focus on verifying the project
require-ments and that the application lends itself to a DSDM approach
Functional Model iterations are focussed on developing GUI solutions
which meet the business requirements.
Design and Build iterations ensure that the application is properly
engineered Implementation phase involves handing over working
application to end users and agreeing the next stage or increment.
Involving users – roles and JAD

DSDM is a user-centred approach. The system belongs to the users. A
DSDM team consists of developers and users working together. The users
have the following roles in the team:
• Ambassador users join the development teams and are chosen to

represent the the entire user base
62
• A Visionary user is responsible for overall direction and objectives of

the project
• Advisor users can be brought in to assist specific prototype or testing
efforts. The developers can have roles in the team which include the following:
• Technical coordinator
• Team-leader
• Developer
• Tester
• Scribe
• Facilitator
The team makes use of JAD workshops (or Facilitated workshops). These
sessions are used to gather requirements information. JAD sessions are well-
organised. Each JAD session should have a clear objective and a published
agenda. A facilitator is assigned to ensure that the meeting sticks to the
agenda. Scribes capture and communicate the results of the session. Using
JAD workshops brings both direct and indirect benefits to a project:
• Rapid, quality decision-making.
• Greater user involvement and enthusiasm.
• Building team spirit
• Process redesign by the user community..
• Clarification of requirements when they are unclear.
9.5. Other methods

There have been many other methods proposed for user-centred design, including:
• Open Systems Task Analysis (OSTA) (Eason, 1988)
• Multiview (Avison and Wood-Harper, 1990)
63
• Effective Technical and Human Implementation of Computer based

Systems (ETHICS) (Mumford, 1995)
• . . . and many others in recent years
64
Revision Questions
Example . ...
Solution: ...
EXERCISE 8. ....
65
LESSON 10
Usability Engineering
10.1. Introduction
Usability engineering (UE) is a systematic approach to making software easier to
use for the individuals who actually use it to get their work done. It is an approach
to the development of software and systems which involves user participation
from the outset and guarantees the usefulness of the product through the use of
a usability specification and metrics. UE thus refers to the entire process of
producing usable software products from requirements gathering to installation.
UE is based on a User-Centered Design (UCD) approach to analysis and design.
10.2. The Usability Engineering lifecycle

• Stage Information produced
• Know the user User characteristics, User background
• Know the task User’s current task, Task analysis
• User requirements capture User requirements
• Setting usability goals Usability specification
• Design process Design
• Apply guidelines, heuristics Feedback for design
• Prototyping Prototype for user testing
• Evaluation with users Feedback for design
• Redesign and evaluate with users Finished product
• Evaluate with users and report Feedback on product for future systems
66
10.3. Task Analysis

Task analysis analyses what a user is required to do in terms of actions and/or cog-
nitive processes to achieve a task. A detailed task analysis can be conducted to
understand the current system and the information flows within it. These infor-mation
flows are important to the maintenance of the existing system and must be
incorporated or substituted in any new system. Task analysis makes it possible to
design and allocate tasks appropriately within the new system. The functions to be
included within the system and the user interface can then be accurately specified.
Task analysis provides knowledge of the tasks that the user wishes to perform
10.3.1. Hierarchical Task Analysis (HTA)

HTA describes a task in terms of a hierarchy of plans and actions. It involves
iterative decomposition of tasks into smaller subtasks HTA is best used to
analyze tasks where a clear goal can be determined and tasks and subtasks are
required to accomplish the goal. The indication of variable steps and sequences
is an essential part of task modeling, for there is always a degree of variation in
the way tasks are performed. HTA is best used for analyzing relatively simple
cognitive and physical tasks. An outline HTA for adding a new bookmark and
folder in a web browser Task modelling is often done using software tools which
allow the task hierarchy to be designed and viewed interactively.
10.3.2. Cognitive Task Analysis and GOMS

The purpose of cognitive task analysis is to model the actions and especially the
knowledge and thinking that learners engage in when performing some task. It
fo-cuses more on the underlying knowledge, skills, and structures of task
performance with a primary goal of acquiring a rich body of knowledge about a
domain from experts and assembling that knowledge into a model. Normally
consists of a de-scription of the actions that performers engage in associated
with the knowledge states necessary to perform those actions; the actions are
not only the behaviors but also the decisions that must be made. CTA methods
for analyzing problem-solving tasks must include the essential features of the
environment, an internal representa-tion of the problem, the relationship between
the problemsolving behavior and the learner’s internal problem representation; a
description of how problems are solved; and what makes problems hard.
67
One widely used method of cognitive task analysis is GOMS –

• Goals – something the user wants to achieve
• Operators – specific actions
• Methods – subgoals or plans
• Selection rules – choosing between methods

GOMS seeks to analyze and model the knowledge and skills that a user
must de-velop in order to perform tasks on a device or system; describes
knowledge of procedures that users perform in a hierarchical
arrangement. Result is a description of the Goals, Operator, Methods and
Selection rules for any task, breaking down tasks into a meaningful series
of goals and sub-goals and continuing until you end up with primitive
psychomotor or mental acts Example Goal (the big picture)
• Go from hotel to the
airport Methods (plans)
• Walk
• Take a bus
• Take a taxi
• Rent a car
Operators (specific actions) for Take a bus method
• Locate bus stop
• Wait for bus
• Get on bus
• and so on. . .
Selection rules (which method)
• Walking is cheaper, but tiring and slow
• Taking a bus is complicated abroad
• And so on. . .
68
10.4. Usability Specification

A usability specification for a system must be capable of being measured so that,
once the system is complete, the degree of compliance with the specification can
be measured. Thus specific criteria must be stated in a way that allows
qualitative, or preferably quantitative, targets to be expressed. An example of a
non-specific criterion is the phrase user friendly. More specific and measurable
criteria might include ease of use, which can be only stated against a specified
task and which has sub-criteria against which it can be measured. For example a
word processing system may define an initial task as follows.
Start the system, enter a single paragraph consisting of three given sentences
with default character and paragraph formatting, print the document and save it
in a named file before exiting from the system. This is a precise statement of a
task which has to be performed. The performance of the user should be
measured. Per-formance measures are called usability metrics. The simplest
measurement to make is the success, or degree of success, in completing the
task. However, there are ad-ditional aspects of the user’s behaviour which are
capable of being measured which include the following:
• the amount of time which the user takes to complete the task
• the number of mistakes which the user makes in completing the task
• the amount of assistance which the user asks for
• the number of distinct commands which the user issues
• the user’s attitude towards the software after completing the task.
The amount of general computer and application specific expertise which

the user has will effect their performance on the task. Assuming
application specific exper-tise users can be categorised into:
• novice users who have never or very rarely used a computer,
• occasional users who might be regular users of computers but only

occasion-ally use a computer to perform the specified task
• expert users who use a computer to perform the specified task on a daily basis.
69
10.5. Guidelines and standards

10.5.1. Principles and Rules
The best user interface design guidelines are high level and widely
applicable di-recting principles, for example:
• Know the user population
• Reduce cognitive load
• Engineer for errors
• Maintain consistency and clarity
People sometimes confuse principles with design rules. Design rules are instruc-
tions which can be obeyed with minimal interpretation by the user. For example,
specifying that all dates in a system should be displayed or entered in the format
DD-MM-YYYY is a design rule. Principles, on the other hand, must be interpreted
and translated into a strategy for producing clear-cut design rules. Which of the
following do you think are principles, and which are design rules?
• Always show a Confirm Delete dialogue box before deleting a file
• Design for user growth
• Allow input flexibility
• Display the quit button at the top of each screen
• Adapt to different user levels and styles
10.5.2. Where do guidelines come from?

There are two main origins:
• Psychological theory
• Practical experience
A wide range of HCI guidelines are available, some very general and some
specific to particular systems. The latter are often specified as standards.
70
Shneiderman’s Eight Golden Rules

To improve the usability of an application it is important to have a well
designed interface. Shneiderman’s "Eight Golden Rules of Interface
Design" are a guide to good interaction design.
1. Strive for consistency.

Consistent sequences of actions should be required in similar situations;
iden-tical terminology should be used in prompts, menus, and help
screens; and consistent commands should be employed throughout.
2. Enable frequent users to use shortcuts.

As the frequency of use increases, so do the user’s desires to
reduce the num-ber of interactions and to increase the pace of
interaction. Abbreviations, function keys, hidden commands, and
macro facilities are very helpful to an expert user.
3. Offer informative feedback.

For every operator action, there should be some system feedback. For
fre-quent and minor actions, the response can be modest, while for
infrequent and major actions, the response should be more substantial.
4. Design dialog to yield closure.

Sequences of actions should be organized into groups with a beginning,
mid-dle, and end. The informative feedback at the completion of a group
of ac-tions gives the operators the satisfaction of accomplishment.
5. Offer simple error handling.

As much as possible, design the system so the user cannot make a serious
error. If an error is made, the system should be able to detect the error and
offer simple, comprehensible mechanisms for handling the error.
6. Permit easy reversal of actions.

This feature relieves anxiety, since the user knows that errors can be undone;
it thus encourages exploration of unfamiliar options. The units of reversibility
may be a single action, a data entry, or a complete group of actions.
71
7. Support internal locus of control.

Experienced operators strongly desire the sense that they are in charge of
the system and that the system responds to their actions. Design the
system to make users the initiators of actions rather than the responders.
8. Reduce short-term memory load.

The limitation of human information processing in short-term memory re-
quires that displays be kept simple, multiple page displays be consolidated,
window-motion frequency be reduced, and sufficient training time be
allotted for codes, mnemonics, and sequences of actions.
10.5.3. Hix and Hartson’s Guidelines

1. User-centred design
2. Know the user
3. Involve the user
4. Prevent user errors
5. Optimize user operations
6. Keep control with the user
7. Help the user to get started
8. Give a task-based mental model
9. Be consistent
10. Keep it simple
11. Design for memory limitations
12. Use recognition rather than recall
13. Use cognitive directiness
14. Draw on real-world analogies
72
15. Use informative feedback
16. Give status indicators
17. Use user-centred wording
18. Use non-threatening wording
19. Use specific, constructive advice
20. Make the system take the blame
21. Do not anthropomorphize (e.g. computer saying good morning)
22. Use modes cautiously
23. Make user actions reversible
24. Get attention judiciously (don’t overuse attention grabbing devices!)
25. Maintain display inertia
26. organise screen to manage complexity
27. Accommodate individual differences
10.5.4. Nielsen’s Usability Heuristics

Nielsen1 lists ten usability heuristics for user interfaces, and these are
commonly used in relation to web interfaces. The heuristics are listed
below with comments on their applicability to the web.
1. Visibility of system status

The system should always keep users informed about what is going
on, through appropriate feedback within reasonable time. Probably
the two most impor-tant things that users need to know are "Where
am I?" and "Where can I go next?"
2. Match between system and the real world

The system should speak the users’ language, with words, phrases and con-
cepts familiar to the user, rather than system-oriented terms. Follow real-world
conventions, making information appear in a natural and logical order.
73
On the web, you have to be aware that users will probably be coming from
diverse backgrounds, so figuring out their "language" can be a challenge.
3. User control and freedom

Users often choose system functions by mistake and will need a clearly marked
"emergency exit" to leave the unwanted state without having to go through an
extended dialogue. Support undo and redo. Some "emergency exits" are pro-
vided by the browser, for example the ‘Back’ button, but there is still plenty of
room on your site to support user control and freedom. A "home" button on
every page is a simple way to let users feel in control of your site.
4. Consistency and standards

Users should not have to wonder whether different words, situations, or ac-
tions mean the same thing. Follow platform conventions. "Platform conven-
tions" on the web means realizing your site is not an island. Users will be
jumping onto (and off of) your site from others, so you need to fit in with the
rest of the web to some degree. "Standards" on the web means follow-ing
HTML and other specifications. Deviations form the standards will be
opportunities for unusable features to creep into your site.
5. Error prevention
Even better than good error messages is a careful design which
prevents a problem from occurring in the first place. Because of the
limitations of HTML forms, inputting information on the web is a
common source of errors for users.
6. Recognition rather than recall

Make objects, actions, and options visible. The user should not have to re-
member information from one part of the dialogue to another. Instructions for
use of the system should be visible or easily retrievable whenever appro-
priate. For the web, this heuristic is closely related to system status. If users
can recognize where they are by looking at the current page, without having to
recall their path from the home page, they are less likely to get lost.
7. Flexibility and efficiency of use
74
Accelerators – unseen by the novice user – may often speed up the interaction
for the expert user such that the system can cater to both inexperienced and
experienced users. Allow users to tailor frequent actions. Some of the best
accelerators are provided by the browser, such as bookmarks. Make pages at
your site easy to bookmark. Do not use frames in a way that prevent users
from bookmarking effectively. Design to be linked to. If the contents of your site
can easily be linked to, others can create specialized views of your site for
specific users and tasks. Amazon.com’s associates program is just one
example of the value of being easy to link to.
8. Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely
needed. Every extra unit of information in a dialogue competes with the
relevant units of information and diminishes their relative visibility. Make
sure your content is written for the web and not just a repackaged
brochure. Break information into chunks and use links to connect the
relevant chunks so that you can sup-port different uses of your content.
9. Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes),
precisely indicate the problem, and constructively suggest a solution. For
example, if a user’s search yields no hits, do not just suggest broadening
the search. Provide a link that will broaden the search for the user.
10. Help and documentation

Even though it is better if the system can be used without
documentation, it may be necessary to provide help and documentation.
Any such information should be easy to search, focused on the user’s
task, list concrete steps to be carried out, and not be too large.
For the web, the key is to not just slap up some help pages, but to integrate
the documentation into your site. You will note that these sets of guidelines
have a lot in common, as they are based on similar research and experience.
75
10.6. Accessibility Guidelines for Web Sites

Web technology has inadvertently created barriers for people with disabilities:
"new" web content is not just text - it also combines graphics, audio, and
video, severely limiting efficient communication for users with no visual or
hearing capabilities for example. As the web rapidly displaces existing media,
there is an increasing social expectation for its accessibility and also a growing
trend to require this accessibility. The web standards organization, W3C,
launched the Web Accessibility Initiative (WAI) program in 1997. W3C provide
the following guidelines for accessible web sites:
• Guideline 1. Provide equivalent alternatives to auditory and visual

content. Provide content that, when presented to the user, conveys
essentially the same function or purpose as auditory or visual content
• Guideline 2. Don’t rely on colour alone. Ensure that text and graphics
are understandable when viewed without colour.
• Guideline 3. Use markup and style sheets and do so properly. Mark up

documents with the proper structural elements. Control presentation
with style sheets rather than with presentation elements and attributes.
• Guideline 4. Clarify natural language usage Use markup that facilitates

pro-nunciation or interpretation of abbreviated or foreign text.
• Guideline 5. Create tables that transform gracefully. Ensure that

tables have necessary markup to be transformed by accessible
browsers and other user agents.
• Guideline 6. Ensure that pages featuring new technologies transform

grace-fully. Ensure that pages are accessible even when newer
technologies are not supported or are turned off.
• Guideline 7. Ensure user control of time-sensitive content changes.

Ensure that moving, blinking, scrolling, or auto-updating objects or
pages may be paused or stopped.
76
• Guideline 8. Ensure direct accessibility of embedded user interfaces. En-

sure that the user interface follows principles of accessible design: device-
independent access to functionality, keyboard operability, self-voicing, etc.
• Guideline 9. Design for device-independence. Use features that

enable acti-vation of page elements via a variety of input devices.
• Guideline 10. Use interim solutions. Use interim accessibility solutions

so that assistive technologies and older browsers will operate correctly.
• Guideline 11. Use W3C technologies and guidelines.
• Guideline 12. Provide context and orientation information. Provide

context and orientation information to help users understand
complex pages or ele-ments.
• Guideline 13. Provide clear navigation mechanisms. Provide clear

and con-sistent navigation mechanisms – orientation information,
navigation bars, a site map, etc. – to increase the likelihood that a
person will find what they are looking for at a site.
• Guideline 14. Ensure that documents are clear and simple. The US
Govern-ment has published similar guidelines, which are legally
enforced for govern-ment agency sites, under Section 508 of the
Americans with Disabilities Act. Designers who are creating sites which
may have an audience in the USA should be aware of these guidelines.
10.7. Standards
Specific guidelines are often expressed as standards. Standards are developed
and promoted by a wide range of organisations for many different reasons.
10.7.1. International standards bodies

These include:
• International Organization for Standardization (ISO)
• American National Standards Institute (ANSI)
77
• British Standards Institute (BSI)
• Worldwide Web Consortium (W3C)
Examples of ISO Standards

ISO 9421 – Ergonomics for Office Work with Virtual Display Terminals
ISO 14915 – Ergonomics for Multimedia User Interface Design
BS EN ISO 13407- Human Centred Design for Interactive
Systems A list of HCI standards can be found at:
http://www.hostserver150.com/usabilit/tools/r_international.htm
Usability standards are increasingly emphasising accessibility.
"The power of the Web is in its universality. Access by everyone
regardless of disability is an essential aspect."
– Tim Berners-Lee, W3C Director and inventor of the World Wide Web
Industry standards
These are published by major players in the software industry, for example:
• The User Interface Guidelines for Microsoft Windows
• Apple Macintosh Human Interface Guidelines
• IBM Web Design Guidelines
These examples are guidelines which aim to promote consistency in the

behaviour and interface of all applications on the Windows platform, or on the
Macintosh platform de Facto standards These are standard largely because they
have been widely adopted. The QWERTY keyboard is a good example of this.
House style guides

These differ from industry standards in that they are developed by
organizations for their own internal use. They can be based on industry
standards, while additionally describing issues specific to the organization.
78
Revision Questions
Example . ...
Solution: ...
EXERCISE 9. ....
79

HCI Notes

Uploaded by

Document Information

Original Description:

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

HCI Notes

Uploaded by

Copyright:

Available Formats

HUMAN COMPUTER INTERACTION

SCO307 HUMAN COMPUTER INTERACTION

Prerequisite: SMA191: Introduction to Computer Programming

2. Describe the techniques and skills required to develop more usable

3. Undertake user interface design for an interactive computing system.

4. Evaluate the usability and functionality of an information system

2. Laura Leventhal, Julie Barnes (2007). Usability Engineering: Process, Prod-

3. Barfield (1993) .The User Interface: Concepts and Design, Addison-Wesley

2. Advances in Computational Mathematics ISSN 1019-7168

3. Advances in data Analysis and Classification ISSN1 1862-5347 4

4. Annals Of software Engineering ISSN 1022-7091

2. Serengul Smith-Atakan (2006). Human Computer Interaction.

3. Shneiderman B (2009). Designing the User Interface: strategies for Effective

2. Journal of Science and Technology ISSN 1860-4749

3. Central European Journal Of Computer Science ISSN 1896-1533

4. Cluster computing ISSN 1386-7857

• 30% Continuous Assessment (Tests 10%, Assignment 10%, Practical 10%)

• 70% End of Semester Examination.

3 Perception and representation 16

3.2.4 Link affordance in web sites . . . .............. 18

4 Attention and memory 24

5 Knowledge and Mental Models 31

6.2.4 Composite metaphors . . . . . . . . . . . . . . ...... 41

• understand the factors that determine how people use technology

• develop tools and techniques to enable building suitable systems

• achieve efficient, effective, and safe interaction

• put people first

• easy to remember how to use

1.3.1. Why is usability important?

1. The photocopier makes the copies correctly.

2. The photocopier settings are cleared and no copies are made.

1.3.2. Factors affecting usability

The principles of visibility and affordance were identified by HCI pioneer

• Visibility is the mapping between a control and its effect. For

• The affordance of an object is the sort of operations and manipulations

1.4. HCI and its evolution

• Human factors engineering (Frank Gilbreth, post World War 1) –

• Aircraft cockpits (World War 2) – emphasis switched to perceptual

• Symbiosis (J.C.R. Licklider, 1960’s) - human operator and computer form

• Cognitive psychology (Donald Norman and many others, late 1970’s,

• Development of GUI interface (Xerox, Apple, early 1980’s)

• Development of software design tools (e.g. Visual Basic, late 1980’s,

• Usability engineering (Jakob Neilsen, 1990’s) - mainly in industry

1.5. Factors in HCI

– Training, job design, politics, roles, work organisation

– Noise, heating, lighting, ventilation

• Health and Safety Factors

– The User Cognitive processes and capabilities

– Seating, equipment, layout.

– Input devices, output devices, dialogue structures, use of colour,

– Easy, complex, novel, task allocation, monitoring, skills

– Cost, timescales, budgets, staff, equipment, buildings

– Hardware, software, application

– Increase output, increase quality, decrease costs, decrease

1.6. Disciplines contributing to HCI

• Computer Science and technology

– software design, development & maintenance

• Cognitive Psychology and information processing

• Social Psychology and social & organizational structures

– natural language interfaces

• Philosophy, Sociology & Anthropology

– Computer supported cooperative work (CSCW)

• Engineering & Design o graphic design