The
terms of interaction
Traditionally,
the purpose of an interactive system is to aid a user in accomplishing goals
from some application domain. A domain defines an area of expertise and
knowledge in some real-world activity. Some examples of domains are graphic
design, authoring and process control in a factory. A domain consists of
concepts that highlight its important aspects. In a graphic design domain, some
of the important concepts are geometric shapes, a drawing surface and a drawing
utensil. Tasks are operations to manipulate the concepts of a domain. A goal is
the desired output from a performed task. For example, one task within the
graphic design domain is the construction of a specific geometric shape with
particular attributes on the drawing surface. A related goal would be to
produce a solid red triangle centered on the canvas. An intention is a specific
action required to meet the goal.
Task
analysis involves the identification of the problem space for the user of an interactive system in terms
of the domain, goals, intentions and tasks. We can use our knowledge of tasks
and goals to assess the interactive system that is designed to support them. The concepts used in the design of the system and the description
of the user are separate, and so we can refer to them as distinct components,
called the System and the User, respectively. The System and User are each
described by means of a language that can express concepts relevant in the
domain of the application. The System’s language we will refer to as the core
language and the User’s language we will refer to as the task language. The
core language describes computational attributes of the domain relevant to the
System state, whereas the task language describes psychological attributes of
the domain relevant to the User state. The system is assumed to be some
computerized application, in the context of this book, but the models apply
equally to non-computer applications. It is also a common assumption that by
distinguishing between user and system we are restricted to single-user
applications. This is not the case. However, the emphasis is on the view of the
interaction from a single user’s perspective. From this point of view, other users,
such as those in a multi-party conferencing system, form part of the system.
The
execution - evaluation cycle
Norman’s
model of interaction is perhaps the most influential in Human–Computer Interaction,
possibly because of its closeness to our intuitive understanding of the interaction
between human user and computer. The user formulates a plan of action, which is
then executed at the computer interface. When the plan, or part of the plan,
has been executed, the user observes the computer interface to evaluate the result
of the executed plan, and to determine further actions. The interactive cycle
can be divided into two major phases: execution and evaluation. These can then
be subdivided into further stages, seven in all. The stages in Norman’s model
of interaction are as follows :
1.
Establishing the goal.
2.
Forming the intention.
3.
Specifying the action sequence.
4.
Executing the action.
5.
Perceiving the system state.
6.
Interpreting the system state.
7.
Evaluating the system state with respect to the goals and intentions.
Each
stage is, of course, an activity of the user. First the user forms a goal. This
is the user’s notion of what needs to be done and is framed in terms of the
domain, in the task language. It is liable to be imprecise and therefore needs
to be translated into the more specific intention, and the actual actions that
will reach the goal, before it can be executed by the user. The user perceives
the new state of the system, after execution of the action sequence, and
interprets it in terms of his expectations. If the system state reflects the
user’s goal then the computer has done what he wanted and the interaction has
been successful; otherwise the user must formulate a new goal and repeat the
cycle.
Norman
uses a simple example of switching on a light to illustrate this cycle. Imagine
you are sitting reading as evening falls. You decide you need more light; that
is you establish the goal to get more light. From there you form an intention to
switch on the desk lamp, and you specify the actions required, to reach over
and press the lamp switch. If someone else is closer the intention may be different,
you may ask them to switch on the light for you. Your goal is the same but the
intention and actions are different. When you have executed the action you
perceive the result, either the light is on or it isn’t and you interpret this,
based on your knowledge of the world. For example, if the light does not come
on you may interpret this as indicating the bulb has blown or the lamp is not
plugged into the mains, and you will formulate new goals to deal with this. If
the light does come on, you will evaluate the new state according to the
original goals, is there now enough light ? If so, the cycle is complete. If
not, you may formulate a new intention to switch on the main ceiling light as
well.
Norman
uses this model of interaction to demonstrate why some interfaces cause problems
to their users. He describes these in terms of the gulfs of execution and the gulfs
of evaluation. As we noted earlier, the user and the system do not use the same
terms to describe the domain and goals, remember that we called the language of
the system the core language and the language of the user the task language. The
gulf of execution is the difference between the user’s formulation of the
actions to reach the goal and the actions allowed by the system. If the actions
allowed by the system correspond to those intended by the user, the interaction
will be effective. The interface should therefore aim to reduce this gulf. The
gulf of evaluation is the distance between the physical presentation of the system
state and the expectation of the user. If the user can readily evaluate the presentation
in terms of his goal, the gulf of evaluation is small. The more effort that is
required on the part of the user to interpret the presentation, the less
effective the interaction.
Norman’s
model is a useful means of understanding the interaction, in a way that is
clear and intuitive. It allows other, more detailed, empirical and analytic
work to be placed within a common framework. However, it only considers the
system as far as the interface. It concentrates wholly on the user’s view of
the interaction. It does not attempt to deal with the system’s communication
through the interface. An extension of Norman’s model, proposed by Abowd and
Beale, addresses this problem. This is described in the next section.
The
interaction framework
 |
| Figure 1 Interaction Framework |
The
interaction framework attempts a more realistic description of interaction by including
the system explicitly, and breaks it into four main components, as shown in
Figure 1. The nodes represent the four major components in an interactive
system, the System, the User, the Input and the Output. Each component has its
own language. In addition to the User’s task language and the System’s core
language, which we have already introduced, there are languages for both the
Input and Output components. Input and Output together form the Interface. As
the interface sits between the User and the System, there are four steps in the
interactive cycle, each corresponding to a translation from one component to another,
as shown by the labeled arcs in Figure 2. The User begins the interactive cycle
with the formulation of a goal and a task to achieve that goal. The only way the
user can manipulate the machine is through the Input, and so the task must be articulated
within the input language. The input language is translated into the core language
as operations to be performed by the System. The System then transforms itself
as described by the operations; the execution phase of the cycle is complete
and the evaluation phase now begins. The System is in a new state, which must
now be communicated to the User. The current values of system attributes are
rendered as concepts or features of the Output. It is then up to the User to
observe the Output and assess the results of the interaction relative to the
original goal, ending the evaluation phase and, hence, the interactive cycle.
There are four main translations involved in the interaction : articulation,
performance, presentation and observation.
The
User’s formulation of the desired task to achieve some goal needs to be
articulated in the input language. The tasks are responses of the User and they
need to be translated to stimuli for the Input. As pointed out above, this
articulation is judged in terms of the coverage from tasks to input and the
relative ease with which the translation can be accomplished. The task is
phrased in terms of certain psychological attributes that highlight the
important features of the domain for the User. If these psychological
attributes map clearly onto the input language, then articulation of the task
will be made much simpler. An example of a poor mapping, as pointed out by
Norman, is a large room with overhead lighting controlled by a bank of switches.
It is often desirable to control the lighting so that only one section of the room
is lit. We are then faced with the puzzle of determining which switch controls which
lights. The result is usually repeated trials and frustration. This arises from
the difficulty of articulating a goal (for example, ‘Turn on the lights in the
front of the room’) in an input language that consists of a linear row of
switches, which may or may not be oriented to reflect the room layout.
Conversely,
an example of a good mapping is in virtual reality systems, where input devices
such as datagloves are specifically geared towards easing articulation by
making the user’s psychological notion of gesturing an act that can be directly
realized at the interface. Direct manipulation interfaces, such as those found
on common desktop operating systems like the Macintosh and Windows, make the articulation
of some file handling commands easier. On the other hand, some tasks, such as
repetitive file renaming or launching a program whose icon is not visible, are not
at all easy to articulate with such an interface. At the next stage, the
responses of the Input are translated to stimuli for the System. Of interest in
assessing this translation is whether the translated input language can reach
as many states of the System as is possible using the System stimuli directly. For
example, the remote control units for some compact disc players do not allow
the user to turn the power off on the player unit; hence the off state of the player
cannot be reached using the remote control’s input language. On the panel of the
compact disc player, however, there is usually a button that controls the
power.
The
ease with which this translation from Input to System takes place is of less
importance because the effort is not expended by the user. However, there can
be a real effort expended by the designer and programmer. In this case, the
ease of the translation is viewed in terms of the cost of implementation. Once
a state transition has occurred within the System, the execution phase of the
interaction is complete and the evaluation phase begins. The new state of the System
must be communicated to the User, and this begins by translating the System responses
to the transition into stimuli for the Output component. This presentation translation
must preserve the relevant system attributes from the domain in the limited
expressiveness of the output devices. The ability to capture the domain
concepts of the System within the Output is a question of expressiveness for
this translation. For example, while writing a paper with some word-processing
package, it is necessary at times to see both the immediate surrounding text
where one is currently composing, say, the current paragraph, and a wider
context within the whole paper that cannot be easily displayed on one screen. Ultimately,
the user must interpret the output to evaluate what has happened. The response
from the Output is translated to stimuli for the User which trigger assessment.
The observation translation will address the ease and coverage of this final translation.
For example, it is difficult to tell the time accurately on an unmarked analog
clock, especially if it is not oriented properly. It is difficult in a command line
interface to determine the result of copying and moving files in a hierarchical
file system. Developing a website using a markup language like HTML would be virtually
impossible without being able to preview the output through a browser.
Assessing
overall interaction The interaction framework is presented as a means to judge
the overall usability of an entire interactive system. In reality, all of the
analysis that is suggested by the framework is dependent on the current task
(or set of tasks) in which the User is engaged. This is not surprising since it
is only in attempting to perform a particular task within some domain that we
are able to determine if the tools we use are adequate. For example, different
text editors are better at different things. For a particular editing task, one
can choose the text editor best suited for interaction relative to the task.
The best editor, if we are forced to choose only one, is the one that best
suits the tasks most frequently performed. Therefore, it is not too disappointing
that we cannot extend the interaction analysis beyond the scope of a particular
task.
Source
: Alan Dix, Human Computer Interaction, 3rd Edition, 2004, Prentice-Hall
Comments
Post a Comment