HUMAN-COMPUTER INTERACTION
SECOND EDITION
Sometimes it may not be clear what the appropriate command is, but once we know one, the rest become obvious. For example, consider a simple database displaying a list of records. We are expecting two commands, one to move up the list to the previous record, and another to move down the list to the next record. There are several options for the commands, for instance UP/DOWN, PREVIOUS/ NEXT, possibly in upper or lower case, possibly also just the first letter of the relevant word. In addition, one might have mixed-up command sets such as UP/ NEXT or N/previous. The fact that any of the former set of commands is easier to learn than the mixed-up commands is called congruence. TAG has a notation to describe the congruence of an interface. The notation F('next') is used to denote the feature set related to the word 'next'. That is, next/previous. With this notation a congruent grammar requires only one 'real' rule, such as
browse[Direction] := F('next') + return * browse[Direction=up] := 'previous' + return * browse[Direction=down] := 'next' + return
However, the task of finding a similar letter would be exploratory, searching through folders, etc. Such recognition-based searching is extremely difficult to represent as a goal structure. Similarly the actual editing would depend very much on non-planned activities: 'ah yes, I want to reuse that bit, but I'll have to change that'. If we then drop to a lower level again, goal hierarchies become more applicable. For instance, during the editing stage we might have the 'delete a word' subdialog:
DELETE_WORD . SELECT_WORD . . MOVE_MOUSE_TO_WORD_START . . DEPRESS_MOUSE_BUTTON . . MOVE_MOUSE_TO_WORD_END . . RELEASE_MOUSE_BUTTON. CLICK_ON_DELETE . . MOVE_MOUSE_TO_DELETE_ICON . . CLICK_MOUSE_BUTTON
Compared with the deep cognitive understanding required to describe problem-solving activities, the human motor system is well understood. KLM (Keystroke-Level Model [36]) uses this understanding as a basis for detailed predictions about user performance. It is aimed at unit tasks within interaction -- the execution of simple command sequences, typically taking no more than 20 seconds. Examples of this would be using a search and replace feature, or changing the font of a word. It does not extend to complex actions such as producing a diagram. The assumption is that these more complex tasks would be split into subtasks (as in GOMS) before the user attempts to map these into physical actions. The task is split into two phases:
The mental operator is probably the most complex part of KLM. Remember that the user is assumed to have decided what to do, and how to do it. The mental preparation is thus just the slight pauses made as the user recalls what to do next. There are complicated heuristics for deciding where to put M operators, but they all boil down to the level of chunking (see Chapter 1 for a discussion of chunking). If the user types a word, or a well-known command name, this will be one chunk, and hence only require one mental operator. However, if a command name were an acronym which the user was recalling letter by letter, then we would place one M operator per letter.
However, we have seen that one has to be quite careful, as the approximations one makes can radically change the results -- KLM is a guide, not an oracle. One should also add a word of caution about the assumption that fastest is best. There are certainly situations where this is so, for example highly repetitive tasks such as telephony or data entry. However, even expert users will often not use the fastest method. For example, the expert may have a set of general-purpose, non-optimal methods, rather than a few task-specific methods.
The architecture of ICS is built up by the coordinated activity of nine smaller subsystems: five peripheral subsystems are in contact with the physical world and four are central, dealing with mental processes. Each subsystem has the same generic structure. A subsystem is described in terms of its typed inputs and outputs along with a memory store for holding typed information. It has transformation functions for processing the input and producing the output and permanently stored information. Each of the nine subsystems is specialized for handling some aspect of external or internal processing. For example, one peripheral subsystem is the visual system for describing what is seen in the world. An example of a central
The scope of task analysis is quite wide. In addition to those tasks which directly involve a computer, the task analyst will typically model aspects of the world that are not, and are not expected to be, part of a computer system. So a task analysis of word processing would include activities such as fetching documents from the filing cabinet, changing the printer ribbon and putting floppy disks in and out of the computer as well as the more obvious interaction with the machine.
However, the mention of cups makes us wonder: do we really only want to describe the making of a single cup of tea? Perhaps we ought to allow several cups of tea to be made. To do this we modify the plan to allow repetitions of steps 1--3 for each cup. We could describe this plan in words, or use a simple diagram as in Figure 7.3.
The easiest source of data for the analyst is the existing manuals, instruction booklets, training materials, etc., for the task. These are most likely to be focused on specific items of equipment or computer software, but this is often the focus anyway. Furthermore, there may be corporate rule books and job descriptions which may be used to obtain information about tasks in a wider context. It should be remembered that these sources typically tell you how people are supposed to perform tasks, not what they actually do. In addition, equipment-specific manuals are likely to tell you about the functions of the device rather than the way it is used to perform a specific task. For example, a word processor may describe a centring menu option, but this would be used as part of specific tasks such as writing a chapter title or producing a figure caption.
Although the structure of material in these sources may be misleading, they are useful for providing basic actions and objects involved in a task. These lists may be incomplete, as they will often ignore non-device actions. For example, the word-processor manual may not mention the use of physical filing cabinets. However, manuals form a starting point for future analysis, and may be used to structure experimental studies, or interviews; one can ask questions such as 'when do you use the centring option?' Also the lists obtained from manuals may be compared with those of direct observation -- unused facilities or objects may indicate either that the facility is redundant, or that it is part of a rare procedure. It is, of course, just these rare procedures which may be missed entirely by direct observation.
processed in 0.004 seconds
| |
HCI Book 3rd Edition || old HCI 2e home page || search
|
|
feedback to feedback@hcibook.com | hosted by hiraeth mixed media |
|