Unit 2

Interaction design basics

Introduction of Interaction Design
• Interaction design is not just about the artifact that is produced,
whether a physical device or a computer program, but about
understanding and choosing how that is going to affect the way
people work.
• In some cases we may realize that no additional system is required at
all, we may simply suggest a different way of using existing tools.
• Because of this it may be better not to think of designing a system, or
an artifact, but to think instead about designing interventions
• The product of a design exercise is that we intervene to change the
situation as it is; we hope, of course, changing it for the better!
WHAT IS DESIGN?
So what is design?
• A simple definition is: achieving goals within constraints
Goals What is the purpose of the design we are intending to produce?
Who is it for? Why do they want it? For example, if we are designing a
wireless personal movie player, we may think about young affluent users
wanting to watch the latest movies whilst on the move and download free
copies, and perhaps wanting to share the experience with a few friends.
Constraints What materials must we use? What standards must we adopt?
How much can it cost? How much time do we have to develop it? Are
there health and safety issues? In the case of the personal movie player:
does it have to withstand rain? Must we use existing video standards to
download movies? Do we need to build in copyright protection?
The golden rule of design
There are also more generic concepts to understand. The designs we produce may be
different, but often the raw materials are the same. This leads us to the golden rule of design:

In the case of a physical design this is obvious. Look at a chair with a steel frame and one with
a wooden frame.

They are very different: often the steel frames are tubular or thin L or H section steel. In
contrast wooden chairs have thicker solid legs. If you made a wooden chair using the design
for a metal one it would break; if you made the metal one in the design for the wooden one it
would be too heavy to move.

For Human–Computer Interaction the obvious materials are the human and the computer.
That is we must: n understand computers – limitations, capacities, tools, platforms n
understand people – psychological, social aspects, human error
THE PROCESS OF DESIGN
Requirements – what is wanted
The first stage is establishing what exactly is needed. As a precursor to
this it is usually necessary to find out what is currently happening. For
example, how do people currently watch movies? What sort of
personal appliances do they currently use.

There are a number of techniques used for this in HCI: interviewing

people, videotaping them, looking at the documents and objects that
they work with, observing them directly.
Analysis and Design
The results of observation and interview need to be ordered in some
way to bring out key issues and communicate with later stages of
design.

Design- Well, this is all about design, but there is a central stage when
you move from what you want, to how to do it. There are numerous
rules, guidelines and design principles that can be used to help with
this. We need to record our design choices in some way and there are
various notations and methods to do this, including those used to
record the existing situation
Iteration and prototyping
• Humans are complex and we cannot expect to get designs right first
time. We therefore need to evaluate a design to see how well it is
working and where there can be improvements.
• Some forms of evaluation can be done using the design on paper, but
it is hard to get real feedback without trying it out. Most user
interface design therefore involves some form of prototyping,
producing early versions of systems to try out with real users
Implementation and deployment
• Finally, when we are happy with our design, we need to create it and
deploy it. This will involve writing code, perhaps making hardware,
writing documentation and manuals – everything that goes into a real
System that can be given to others.
SCENARIOS
• Scenarios are stories for design: rich stories of interaction. They are
perhaps the simplest design representation, but one of the most
flexible and powerful. Some scenarios are quite short: ‘the user
intends to press the “save” button, but accidental presses the “quit”
button so loses his work’. Others are focussed more on describing the
situation or context.
NAVIGATION DESIGN
Widgets The appropriate choice of widgets and wording in menus and
buttons will help you know how to use them for a particular selection
or action.
Screens or windows You need to find things on the screen, understand
the logical grouping of buttons.
SCREEN DESIGN AND LAYOUT
• The basic principles at the screen level reflect those in other areas of
interaction design:
Ask What is the user doing?
Think What information is required?
What comparisons may the user need to make?
In what order are things likely to be needed?
Design Form follows function: let the required interactions drive the
layout
continue
Tools for Layout
a. Grouping and structure
b. Order of groups and items
c. Decoration
d. Alignment
Grouping and structure

• If things logically belong together, then we should normally physically

group them together. This may involve multiple levels of structure..
Notice how the details for billing and delivery are grouped together
spatially; also note how they are separated from the list of items
actually ordered by a line as well as spatially. This reflects the
following logical structure.
Decoration And Alignment
ITERATION AND PROTOTYPING
• Iteration and prototyping are the universally accepted ‘best practice’
approach for interaction design. However, there are some major
pitfalls of prototyping, rarely acknowledged in the literature.
• Any of these prototypes, whether paper-based or running software,
can then be evaluated to see whether they are acceptable and where
there is room for improvement. This sort of evaluation, intended to
improve designs, is called formative evaluation. This is in contrast to
summative evaluation, which is performed at the end to verify
whether the product is good enough
2. THE SOFTWARE LIFE CYCLE
• In the development of a software product, we consider two main
parties: the customer who requires the use of the product and the
designer who must provide the product.
• Typically, the customer and the designer are groups of people and some
people can be both customer and designer.
• It is often important to distinguish between the customer who is the
client of the designing company and the customer who is the eventual
user of the system.
• These two roles of customer can be played by different people. The
group of people who negotiate the features of the intended system with
the designer may never be actual users of the system
Activities in the life cycle
2.1 Requirement
• In requirements specification, the designer and customer try to capture a
description of what the eventual system will be expected to provide.
• This is in contrast to determining how the system will provide the expected
services, which is the concern of later activities. Requirements specification
involves eliciting information from the customer about the work environment, or
domain, in which the final product will function.
• Requirements specification begins at the start of product development. Though
the requirements are from the customer’s perspective, if they are to be met by the
software product they must be formulated in a language suitable for
implementation.
• Requirements are usually initially expressed in the native language of the
customer. The executable languages for software are less natural and are more
closely related to a mathematical language in which each term in the language has
a precise interpretation, or semantics
2.2 Architectural design
• An architectural design performs this decomposition. It is not only
concerned with the functional decomposition of the system,
determining which components provide which services. It must also
describe the interdependencies between separate components and
the sharing of resources that will arise between components.
• What we will mention here is that the majority of these techniques
are adequate for capturing the functional requirements of the system
– the services the system must provide in the work domain – but do
not provide an immediate way to capture other non-functional
requirements – features of the system that are not directly related to
the actual services provided but relate to the manner in which those
services must be provided
2.3 Detailed design
• The architectural design provides a decomposition of the system
description that allows for isolated development of separate
components which will later be integrated For those components that
are not already available for immediate integration, the designer must
provide a sufficiently detailed description so that they may be
implemented in some programming language
• Thus the language used for the detailed design must allow some
analysis of the design in order to assess its properties. It is also
important to keep track of the design options considered.
2.4 Coding and unit testing
• The detailed design for a component of the system should be in such
a form that it is possible to implement it in some executable
programming language. After coding, the component can be tested to
verify that it performs correctly, according to some test criteria that
were determined in earlier activities.
2.5 Integration and testing
• Once enough components have been implemented and individually
tested, they must be integrated as described in the architectural
design. Further testing is done to ensure correct behavior and
acceptable use of any shared resources. It is also possible at this time
to perform some acceptance testing with the customers to ensure
that the system meets their requirements. It is only after acceptance
of the integrated system that the product is finally released to the
customer.
2.6 Maintenance
• After product release, all work on the system is considered under the
category of maintenance, until such time as a new version of the
product demands a total redesign or the product is phased out
entirely. Consequently, the majority of the lifetime of a product is
spent in the maintenance activity.
Validation and verification
• Throughout the life cycle, the design must be checked to ensure that
it both satisfies the high-level requirements agreed with the customer
and is also complete and internally consistent. These checks are
referred to as validation and verification, respectively. Boehm
provides a useful distinction between the two, characterizing
validation as designing ‘the right thing’ and verification as designing
‘the thing right’.
ITERATIVE DESIGN AND PROTOTYPIN
• Throw-away The prototype is built and tested. The design knowledge
gained from this exercise is used to build the final product, but the
actual prototype is discarded. Figure depicts the procedure in using
throw-away prototypes to arrive at a final requirements specification
in order for the rest of the design process to proceed.
Continue
• Incremental The final product is built as separate components, one at
a time. There is one overall design for the final system, but it is
partitioned into independent and smaller components. The final
product is then released as a series of products, each subsequent
release including one more component. This is depicted in Figure
Evolutionary
• Evolutionary Here the prototype is not discarded and serves as the
basis for the next iteration of design. In this case, the actual system is
seen as evolving from a very limited initial version to its final release,
as depicted in Figure 6.7. Evolutionary prototyping also fits in well
with the modifications which must be made to the system that arise
during the operation and maintenance activity in the life cycle.
3 Design Rule
• One of the central problems that must be solved in a user-centered
design process is how to provide designers with the ability to
determine the usability consequences of their design decisions. We
require design rules, which are rules a designer can follow in order to
increase the usability of the eventual software product.
• We can classify these rules along two dimensions, based on the rule’s
authority and generality. By authority, we mean an indication of
whether or not the rule must be followed in design or whether it is
only suggested. By generality, we mean whether the rule can be
applied to many design situations or whether it is focused on a more
limited application situation.
PRINCIPLES TO SUPPORT USABILITY
• The principles we present are first divided into three main categories:
Learnability – the ease with which new users can begin effective
interaction and achieve maximal performance.
Flexibility – the multiplicity of ways in which the user and system
exchange information.
Robustness – the level of support provided to the user in determining
successful achievement and assessment of goals
Summary of principles affecting learnability
3.1 Learnability
• Predictability
Except when interacting with some video games, a user does not take
very well to surprises. Predictability of an interactive system means that
the user’s knowledge of the interaction history is sufficient to
determine the result of his future interaction. There are many degrees
to which predictability can be satisfied. The knowledge can be
restricted to the presently perceivable information, so that the user
need not remember anything other than what is currently observable.
Continue
• For example, a common mathematical puzzle would be to present you
with a sequence of three or more numbers and ask you what would
be the next number in the sequence. The assumption in this puzzle
(and one that can often be incorrect) is that there is a unique function
or algorithm that produces the entire sequence of numbers and it is
up you to figure it out. We know the function, but all you know are
the results it provides from the first three calculations. The function is
certainly deterministic; the test for you is a test of its predictability
given the first three numbers in the sequence
Synthesizability
• Synthesis, therefore, is the ability of the user to assess the effect of
past operations on the current state.
• When an operation changes some aspect of the internal state, it is
important that the change is seen by the user. The principle of
honesty relates to the ability of the user interface to provide an
observable and informative account of such change. In the best of
circumstances, this notification can come immediately, requiring no
further interaction initiated by the user.
• At the very least, the notification should appear eventually, after
explicit user directives to make the change observable.
continue
• A good example of the distinction between immediacy and
eventuality can be seen in the comparison between command
language interfaces and visual desktop interfaces for a file
management system.
• You have moved a file from one directory to another. The principle of
honesty implies that after moving the file to its new location in the file
system you are then able to determine its new whereabouts.
• In a command language system, you would typically have to
remember the destination directory and then ask to see the contents
of that directory in order to verify that the file has been moved .
continue
• In a visual desktop interface, a visual representation (or icon) of the
file is dragged from its original directory and placed in its destination
directory where it remains visible (assuming the destination folder is
selected to reveal its contents). In this case, the user need not expend
any more effort to assess the result of the move operation. The visual
desktop is immediately honest
Familiarity
• New users of a system bring with them a wealth of experience across a wide
number of application domains. This experience is obtained both through
interaction in the Design rules real world and through interaction with other
computer systems. For a new user, the familiarity of an interactive system
measures the correlation between the user’s existing knowledge and the
knowledge required for effective interaction.
• For example, when word processors were originally introduced the analogy
between the word processor and a typewriter was intended to make the new
technology more immediately accessible to those who had little experience with
the former but a lot of experience with the letter. Familiarity has to do with a
user’s first impression of the system. In this case, we are interested in how the
system is first perceived and whether the user can determine how to initiate any
interaction.
Generalizability
• Users often try to extend their knowledge of specific interaction
behavior to situations that are similar but previously unencountered.
The generalizability of an interactive system supports this activity,
leading to a more complete predictive model of the system for the
user. We can apply generalization to situations in which the user
wants to apply knowledge that helps achieve one particular goal to
another situation where the goal is in some way similar.
Consistency
• Consistency relates to the likeness in behavior arising from similar
situations or similar task objectives. Consistency is probably the most
widely mentioned principle in the literature on user interface design.
‘Be consistent!’ we are constantly urged. Consistency is not a single
property of an interactive system that is either satisfied or not
satisfied. Instead, consistency must be applied relative to something.
Thus we have consistency in command naming, or consistency in
command/argument invocation.
Flexibility
Dialog initiative
• The system can initiate all dialog, in which case the user simply
responds to requests for information. We call this type of dialog
system pre-emptive.
• For example, a modal dialog box prohibits the user from interacting
with the system in any way that does not direct input to the box.
Alternatively, the user may be entirely free to initiate any action
towards the system, in which case the dialog is user pre-emptive.
Task migratability
• Task migratability concerns the transfer of control for execution of
tasks between system and user.
• Spell-checking a paper is a good example of the need for task
migratability. This mundane task is perfectly suited to automation, as
the computer can check words against its own list of acceptable
spellings. It is not desirable, however, to leave this task completely to
the discretion of the cmputer, as most computerized dictionaries do
not handle proper names correctly, nor can they distinguish between
correct and unintentional duplications of words. In those cases, the
task is handed over to the user. The spell-check is best performed in
such a cooperative way
Robustness
Eight Golden Rules of Interface Design
1. Strive for consistency in action sequences, layout, terminology,
command use and so on.
2. Enable frequent users to use shortcuts, such as abbreviations, special
key sequences and macros, to perform regular, familiar actions more
quickly.
3. Offer informative feedback for every user action, at a level
appropriate to the magnitude of the action.
4. Design dialogs to yield closure so that the user knows when they
have completed a task.
Continue
5. Offer error prevention and simple error handling so that, ideally, users
are prevented from making mistakes and, if they do, they are offered clear
and informative instructions to enable them to recover.
6. Permit easy reversal of actions in order to relieve anxiety and encourage
exploration, since the user knows that he can always return to the
previous state.
7. Support internal locus of control so that the user is in control of the
system, which responds to his actions.
8. Reduce short-term memory load by keeping displays simple,
consolidating multiple page displays and providing time for learning action
sequences.
Implementation
• we will discuss the programming support that is provided for the
implementation of an interactive system
• The detailed specification gives the programmer instructions as to what
the interactive application must do and the programmer must translate
that into machine executable instructions to say how that will be
achieved on the available hardware devices.
• The objective of the programmer then is to translate down to the level
of the software that runs the hardware devices. At its crudest level, this
software provides the ability to do things like read events from various
input devices and write primitive graphics commands to a display.
PROGRAMMING THE APPLICATION
• The first programming paradigm is the read–evaluation loop, which is
internal to the application program itself.
• The first programming paradigm is the read–evaluation loop, which is
internal to the application program itself. Programming on the
Macintosh follows this paradigm. The server sends user inputs as
structured events to the client application. As far as the server is
concerned, the only importance of the event is the client to which it
must be directed. The client application is programmed to read any
event passed to it and determine all of the application-specific
behavior that results as a response to it
Continue
• The other programming paradigm is notification based, in which the
main control loop for the event processing does not reside within the
application. Instead, a centralized notifier receives events from the
window system and filters them to the application program in a way
declared by the program.
• The application program informs the notifier what events are of
interest to it, and for each event declares one of its own procedures
as a callback before turning control over to the notifier. When the
notifier receives an event from the window system, it sees if that
event was identified by the application program and, if so, passes the
event and control over to the callback procedure that was registered
for the event. After processing, the callback procedure returns control
to the notifier, either telling it to continue receiving events or
requesting termination
Continue
Evaluation
• Evaluation should not be thought of as a single phase in the design
process Ideally, evaluation should occur throughout the design life
cycle, with the results of the evaluation feeding back into
modifications to the design. Clearly, it is not usually possible to
perform extensive experimental testing continuously throughout the
design, but analytic and informal techniques can and should be used.
• This has the advantage that problems can be ironed out before
considerable effort and resources have been expended on the
implementation itself: it is much easier to change a design in the early
stages of development than in the later stages.
Goal of Evaluation
• Evaluation has three main goals: to assess the extent and accessibility
of the system’s functionality, to assess users’ experience of the
interaction, and to identify any specific problems with the system.
• The system’s functionality is important in that it must accord with the
user’s requirements. In other words, the design of the system should
enable users to perform their intended tasks more easily. This
includes not only making the appropriate functionality available
within the system, but making it clearly reachable by the user in
terms of the actions that the user needs to take to perform the task. It
also involves matching the use of the system to the user’s
expectations of the task
Continue
• In addition to evaluating the system design in terms of its functional
capabilities, it is important to assess the user’s experience of the
interaction and its impact upon him. This includes considering aspects
such as how easy the system is to learn, its usability and the user’s
satisfaction with it.
• The final goal of evaluation is to identify specific problems with the
design. These may be aspects of the design which, when used in their
intended context, cause unexpected results, or confusion amongst
users. This is, of course, related to both the functionality and usability
of the design
EVALUATION THROUGH EXPERT
ANALYSIS
• evaluation should occur throughout the design process. In particular,
the first evaluation of a system should ideally be performed before
any implementation work has started. If the design itself can be
evaluated, expensive mistakes can be avoided, since the design can be
altered prior to any major resource commitments.
• Typically, the later in the design process that an error is discovered,
the more costly it is to put right and, therefore, the less likely it is to
be rectified. a number of methods have been proposed to evaluate
interactive systems through expert analysis. We will consider four
approaches to expert analysis: cognitive walkthrough, heuristic
evaluation, the use of models and use of previous work
To do a walkthrough you need four things
1. A specification or prototype of the system. It doesn’t have to be
complete, but it should be fairly detailed..
2. A description of the task the user is to perform on the system. This
should be a representative task that most users will want to do.
3. A complete, written list of the actions needed to complete the task
with the proposed system.
4. An indication of who the users are and what kind of experience and
knowledge the evaluators can assume about them
1. Cognitive walkthrough
• The origin of the cognitive walkthrough approach to evaluation is the
code walkthrough familiar in software engineering. Walkthroughs
require a detailed review of a sequence of actions.
• In the cognitive walkthrough, the sequence of actions refers to the
steps that an interface will require a user to perform in order to
accomplish some known task.
• The evaluators then ‘step through’ that action sequence to check it
for potential usability problems. Usually, the main focus of the
cognitive walkthrough is to establish how easy a system is to learn
2. Heuristic evaluation
• A heuristic is a guideline or general principle or rule of thumb that can
guide a design decision or be used to critique a decision that has
already been made.
• The general idea behind heuristic evaluation is that several evaluators
independently critique a system to come up with potential usability
problems. It is important that there be several of these evaluators and
that the evaluations be done independently. Nielsen’s experience
indicates that between three and five evaluators is sufficient, with five
usually resulting in about 75% of the overall usability problems being
discovered.
Continue

• Each evaluator assesses the system and notes violations of any of

these heuristics that would indicate a potential usability problem.
• The evaluator also assesses the severity of each usability problem,
based on four factors: how common is the problem, how easy is it for
the user to overcome, will it be a one-off problem or a persistent one,
and how seriously will the problem be perceived?
• These can be combined into an overall severity rating on a scale of 0–
4:
Continue
0 = I don’t agree that this is a usability problem at all
1 = Cosmetic problem only: need not be fixed unless extra time is
available on project
2 = Minor usability problem: fixing this should be given low priority
3 = Major usability problem: important to fix, so should be given high
priority
4 = Usability catastrophe: imperative to fix this before product can be
released
3. Using previous studies in evaluation
• A final approach to expert evaluation exploits this inheritance, using
previous results as evidence to support (or refute) aspects of the
design. It is expensive to repeat experiments continually and an
expert review of relevant literature can avoid the need to do so.
• The review should therefore take account of both the similarities and
the differences between the experimental context and the design
under consideration. This is why this is an expert review: expertise in
the area is required to ensure that correct assumptions are made
UNIVERSAL DESIGN PRINCIPLES
• Universal design as ‘the process of designing products so that they
can be used by as many people as possible in as many situations as
possible’.
• But what does that mean in practice? Is it possible to design anything
so that anyone can use it – and if we could, how practical would it be?
Wouldn’t the cost be prohibitive?
• In reality, we may not be able to design everything to be accessible to
everyone, and we certainly cannot ensure that everyone has the
same experience of using a product, but we can work toward the aim
of universal design and try to provide an equivalent experience
Examples of UNIVERSAL DESIGN
PRINCIPLES
• Next time you cross the road, look at the pavement. The curb may be
lowered, to enable people who use wheelchairs to cross more easily.
The paving near the curb may be of a different texture – with raised to
enable people who cannot see to find the crossing point.
• Notice how many modern buildings have automatic doors that open
on approach. Or lifts that offer both visual and auditory notification of
the floor reached. And, whilst these designs make the crossing, the
building and the lift more accessible to people who have disabilities,
notice too how they also help other users.
Continue
• Principle one is equitable use
The design is useful to people with a range of abilities and appealing to
all.
• Principle two is flexibility in use:
The design allows for a range of ability and preference, through choice
of methods of use and adaptivity to the user’s pace, precision and
custom.
Continue
• Principle three is that the system be simple and intuitive to use,
regardless of the knowledge, experience, language or level of
concentration of the user. The design needs to support the user’s
expectations and accommodate different language and literacy skills.
• Principle four is perceptible information the design should provide
effective communication of information regardless of the
environmental conditions or the user’s abilities. Redundancy of
presentation is important: information should be represented in
different forms or modes (e.g. graphic, verbal, text, touch).
Continue
• Principle five is tolerance for error minimizing the impact and damage
caused by mistakes or unintended behavior. Potentially dangerous
situations should be removed or made hard to reach
• Principle six is low physical effort systems should be designed to be
comfortable to use, minimizing physical effort and fatigue
• Principle seven requires size and space for approach and use the
placement of the system should be such that it can be reached and
used by any user regardless of body size, posture or mobility
MULTI-MODAL INTERACTION
• As we have seen in the previous section, providing access to
information through more than one mode of interaction is an
important principle of universal design. Such design relies on multi-
modal interaction.
• there are five senses: sight, sound, touch, taste and smell.
• Sight is the predominant sense for the majority of people, and most
interactive systems consequently use the visual channel as their
primary means of presentation, through graphics, text, video and
animation
continue
• Music is almost completely an auditory experience, yet is able to alter
moods, conjure up visual images, evoke atmospheres or scenes in the mind
of the listener.
• Touch, too, provides important information: tactile feedback forms an
intrinsic part of the operation of many common tools – cars, musical
instruments, pens, anything that requires holding or moving. It can form a
sensuous bond between individuals, communicating a wealth of non-verbal
information.
• Taste and smell are often less appreciated (until they are absent) but they
also provide useful information in daily life: checking if food is bad, detecting
early signs of fire, noticing that manure has been spread in a field, pleasure
1. Sound in the interface
• Sound is an important contributor to usability. There is experimental
evidence to suggest that the addition of audio confirmation of modes,
in the form of changes in keyclicks, reduces errors.
• Video games offer further evidence, since experts tend to score less
well when the sound is turned off than when it is on; they pick up
vital clues and information from the sound while concentrating their
visual attention on different things.
2. Speech in the interface
• Language is rich and complex. We learn speech naturally as children
‘by example’ – by listening to and mimicking the speech of those
around us. This process seems so effortless that we often do not
appreciate its complex structures, and it is not until we attempt to
learn a new language later in life, or to make explicit the rules of the
one we speak, that the difficulties inherent in language understanding
become apparent. This complexity makes speech recognition and
synthesis by computer very difficult
Continue..

• Structure of speech If we are fully to appreciate the problems involved with the
computer-based recognition and generation of speech, we need first to
understand the basic structure of speech. We will use English to illustrate but
most other languages have similar issues.
• Speech recognition There have been many attempts at developing speech
recognition systems, but, although commercial systems are now commonly and
cheaply available, their success is still limited to single-user systems that require
considerable training.
• Background noise can interfere with the input, masking or distorting the
information, while speakers can introduce redundant or meaningless noises into
the information stream by repeating themselves, pausing or using ‘continuation’
noises such as ‘ummm’ and ‘errr’ to fill in gaps in their usual speech
• Uninterpreted speech- Speech does not have to be recognized by a
computer to be useful in the interface. Fixed pre-recorded messages
can be used to supplement orr eplace visual information. Recordings
have natural human prosody and pronunciation, although quality is
sometimes low. Segments of speech can be used together to
construct messages, for example the announcements in many
airports and railway stations.
• When recordings are replayed, they can be digitally speeded up. If
you simply play an audio recording faster, the pitch rises
• Non-speech sound- Non -speech sound can be used in a number of
ways in interactive systems. It is often used to provide transitory
information, such as indications of network or system changes, or of
errors. It can also be used to provide status information on
background processes, since we are able to ignore continuous sounds
but still respond to changes in those sounds. Users of early home
computers with their noisy power supplies, and computer operators
listening to the chatter of the printer and the spinning of disks and
tape drives, both report that they are able to tell what stage a process
is at by the characteristic sounds that are made.
2 Touch in the interface
• The use of touch in the interface is known as haptic interaction. we
considered a number of examples of haptic devices, including some
based on vibration against the skin (cutaneous) and others on
resistance or force feedback (kinesthethic). They facilitate perception
of properties such as shape, texture, resistance and temperature as
well as comparative spatial properties such as size, height and
position.
3. Handwriting recognition
• Like speech, we consider handwriting to be a very natural form of
communication. The idea of being able to interpret handwritten input
is very appealing, and handwriting appears to offer both textual and
graphical input using the same tools. There are problems associated
with the use of handwriting as an input medium.
• Digitizing tablets have been refined by incorporating a thin screen on
top to display the information, producing electronic paper