HUMAN-COMPUTER INTERACTION
SECOND EDITION
HUMAN-COMPUTER INTERACTION
SECOND EDITION
A classic text in this field of cognitive models, in which the basic architectural assumptions of the Model Human Processor architecture are explained as well as the GOMS model and KLM.
A good description of TAG with several extended examples based on the Macintosh interface. The authors provide a good comparative analysis of TAG versus other cognitive modelling techniques.
The description of the problem space cognitive architecture was informed by this article, which also contains references to essential work on the Soar platform.
Some aspects of task analysis will look very like the goal-oriented cognitive models discussed in Chapter 6. Indeed, there would be little to prevent one using a GOMS-like notation to represent a task decomposition such as the vacuum cleaning above. The difference between the two lies in the intention of the models. The purpose of the goal-oriented models is to understand the internal cognitive processes as a person performs a task -- the granularity is thus usually rather small. The emphasis of task analysis is more one of observing the user from the outside and will include actions, such as retrieval of a document from a filing cabinet, which would never be included in a GOMS analysis.
Sometimes task analysis will produce quite low-level task decompositions which are identical to those one would expect from a goal-oriented analysis. However, for task analysis this would tend to be the end of the process, to be used, for instance, by the interface designer in structuring the dialog. For goal-oriented cognitive models, such a goal hierarchy is the central feature, to be further analyzed for complexity, learnability and the like.
In terms of the design life cycle (Chapter 5) task analysis belongs at the beginning in requirements capture, whereas the cognitive models are normally used towards the end of the process during evaluation.
Another obvious stopping point is where the task contains complex motor responses (like mouse movement) or where it involves internal decision making. In the first case, decomposition would not be productive; explaining how such actions are performed is unlikely to be either accurate or useful. In the second case, we would expand if the decision making were related to external actions, such as looking up documentation or reading instruments, but not where the activity is purely cognitive. A possible exception to this would be if we were planning to build a decision support system, in which case we may want to understand the way someone thought about a problem in order to build tools to help. However, it is debatable whether HTA is the appropriate technique in this case.
It is often claimed that dialog design should be independent of the detailed design of the presentation and lexical details of the interface. That is, one begins by deciding on the functionality of the system, and then, possibly making use of cognitive models or task analysis, one designs the dialog to perform those functions. Finally, one designs the visual presentation of the system and the lexical bindings between keypresses and mouse movement and the more abstract dialog actions.
processed in 0.007 seconds
|
| |
|
HCI Book 3rd Edition || old HCI 2e home page || search
|
|
| feedback to feedback@hcibook.com | hosted by hiraeth mixed media |
|
| |