HUMAN-COMPUTER INTERACTION SECOND EDITION
Dix, Finlay, Abowd and Beale

Search Results

Search results for hierarchy
Showing 10 to 19 of 44 [<< prev] [next >>] [new search]

Chapter 6 Models of the user in design 6.7.2 Cognitive complexity theory Page 235

Cognitive complexity theory (CCT), introduced by Kieras and Polson [128], begins with the basic premises of goal decomposition from GOMS and enriches the model to provide more predictive power. CCT has two parallel descriptions: one of the user's goals and the other of the computer system (called the device in CCT). The description of the user's goals is based on a GOMS-like goal hierarchy, but is expressed primarily using production rules. We introduced production rules in Chapter 1 and we further describe their use in CCT below. For the system grammar, CCT uses generalized transition networks, a form of state transition network. This will not be described here, but state transition networks will be discussed in detail in Chapter 8.

Chapter 6 Models of the user in design 6.7.2 Cognitive complexity theory Page 239

The CCT rules are closely related to GOMS-like goal hierarchies; the rules may be generated from such a hierarchy, or alternatively, we may analyze the production rules to obtain the goal tree:

GOAL: insert space

.    GOAL: move cursor -- if not at right position

.    PRESS-KEY-I

.    PRESS-SPACE

.    PRESS-ESCAPE

Chapter 6 Models of the user in design 6.7.2 Cognitive complexity theory Page 239

The stacking depth of this goal hierarchy (as described for GOMS) is directly related to the number of (GOAL ...) terms in working memory.

Chapter 6 Models of the user in design 6.7.3 Problems and extensions of goal hierarchies Page 240

The formation of a goal hierarchy is largely a post hoc technique and runs a very real risk of being defined by the computer dialog rather than the user. One way to rectify this is to produce a goal structure based on pre-existing manual procedures and thus obtain a natural hierarchy [130]. To be fair, GOMS defines its domain to be that of expert use, and thus the goal structures which are important are those which users develop out of their use of the system. However, such a natural hierarchy may be particularly useful as part of a CCT analysis, representing a very early state of knowledge.

Chapter 6 Models of the user in design 6.7.3 Problems and extensions of goal hierarchies Page 241

Banks (at least some of them) soon changed the dialog order so that the card was always retrieved before the money was dispensed. A general rule that can be applied to any goal hierarchy from this is that no higher level goal should be satisfied until all subgoals have been satisfied. However, it is not always easy to predict when the user will consider a goal to have been satisfied. For instance, one of the authors has been known to collect his card and forget the money!

Chapter 6 Models of the user in design 6.9 The challenge of display-based systems Page 245

Goal hierarchy methods have different problems, as more display-oriented systems encourage less structured methods for goal achievement. Instead of having well-defined plans, the user is seen as performing a more exploratory task, recognizing fruitful directions and backing out of others. Typically, even when this exploratory style is used at one level, we can see within it and around it more goal-oriented methods. So, for example, we might consider the high-level goal structure

WRITE_LETTER

.    FIND_SIMILAR_LETTER

.    COPY_IT

.    EDIT_COPY

Chapter 7 Task analysis 7.2 Differences between task analysis and other techniques Page 262

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.

Chapter 7 Task analysis 7.3 Task decomposition Page 262

The example above of vacuum cleaning showed how a task, 'clean the house', was decomposed into several subtasks: 'get the vacuum cleaner out' and so on. Most task analysis techniques involve some form of task decomposition to express this sort of behaviour. Hierarchical task analysis (HTA) is typical of such an approach [11, 217]. The outputs of HTA are a hierarchy of tasks and subtasks and also plans describing in what order and under what conditions subtasks are performed.

Chapter 7 Task analysis 7.3 Task decomposition Page 262

For example, we could express the house-cleaning example as in Figure 7.1, further decomposing the subtask 'clean rooms'. Indentation is used to denote the levels in the task hierarchy, and the tasks are also numbered to emphasize this hierarchy. The plans are labelled by the task to which they correspond. So plan 0 refers to the way in which we perform the subtasks 1--5 of task 0. Similarly plan 3 refers to the way in which we perform 3.1--3.3. There are no plans for subtasks 1, 2, 4 and 5 as these have not been decomposed.

Chapter 7 Task analysis 7.3 Task decomposition Page 263

Reading the plans, we see that not all the subtasks need be performed, and not necessarily in the order presented. Looking first at plan 0, subtask 4 'empty the dust bag' need only be performed when the dust bag is found to be full. As this is put in plan 0, we assume that we may empty the dust bag at any stage including when we first get the vacuum cleaner out or when we put it away. If we know that we only ever notice the bag is full when we are actively using the machine, we might choose to put this subtask within 3 'clean the rooms'. This sort of restructuring, finding the appropriate and meaningful hierarchy, is part of the process of HTA.

processed in 0.006 seconds