HUMAN-COMPUTER INTERACTION
SECOND EDITION
HUMAN-COMPUTER INTERACTION
SECOND EDITION
How does one produce such a hierarchy with attendant rules? The process is iterative. Assume for the moment that we have some overall task in mind, such as house
The task hierarchy can be represented diagrammatically as well as textually. Figure 7.2 shows a task hierarchy for making a cup of tea. The main task, 'make a cup of tea', is decomposed into six subtasks. Of these only the first, 'boil water', is expanded further. The remaining tasks 2--6 and the subtasks of 1.1--1.4 are underlined showing that the analysis has been deliberately stopped at that point. This obviously denotes the same information as the textual form, but may be more accessible at a glance.
Having produced a first stab at a task hierarchy, one would examine it for errors or omissions. One way of approaching this would be to describe the steps in the task hierarchy to a domain expert. This would quickly show that the plan for making tea
It is the nature of expert knowledge that obvious things get missed for a task description. One way the analyst can search for such omissions is by examining the form of the subtasks. For example, 1.4 says 'turn off gas', but nowhere does it say to turn the gas on! Probably, this was implicit in 'put kettle on stove', but it should be added between tasks 1.2 and 1.3. At this point we might notice that the task hierarchy is a little unbalanced. This might be right, but we may have included too many detailed tasks at the highest level. We choose to add a new top-level node 'make pot' which would encompass the tasks 3 and 4 and also the new 'warm pot' task.
We will begin by looking at simple hierarchies of objects. Consider first the controls in a (non-automatic) motor car. An example taxonomic structure is given in Figure 7.5; every control has exactly one place in the hierarchy.
Look at it for a moment: do you think it is a good one? We will discuss this shortly. Consider how we might have produced such a hierarchy, and how to use it. The car controls are particularly simple, as we can simply get in and look for them all. If we extended our analysis to driving a car in general, we would have to consider more objects: the instruments (speedometer etc.), the car keys, seat-belts, road signs, other cars, etc. Just as with HTA it can be hard to know when to stop. However, with any such procedure it is best to start by listing everything you can, later removing items which are felt to be unnecessary. Other sources for forming a list of objects include manuals, transcripts and observation and will be discussed in Section 7.6.
This better reflects the way they are positioned on most cars, but has no more logic to it than the classification in Figure 7.5. Really, there are two attributes: 'function' (wash or wipe) and 'position' (front or rear). One technique, task analysis for knowledge description (TAKD), uses a special form of taxonomy called task descriptive hierarchy (TDH). TAKD is discussed in detail by Diaper [65] in the recommended reading list at the end of this chapter. The branches in the simple taxonomy are either/or branches -- a car control is either a steering control or an engine/speed control or a lighting control. As well as these XOR branches TDH also uses AND
wash/wipe AND
function XOR
wipe
front wipers, rear wipers
wash
front washers, rear washers
position XOR
front
front wipers, front washers
rear
rear wipers, rear washers
TAKD has a uniqueness rule, which demands that a completed TDH can distinguish any two specific objects. The kitchen hierarchy above fails this test. We can distinguish, say, the plate from the soup bowl, because the plate is in categories preparation and dining, whereas the bowl is only under dining. However, we cannot distinguish the soup bowl from the glass. TAKD would demand that we further refine this hierarchy until all pairs can be distinguished from one another:
kitchen item AND /___ shape XOR / |___ dished / | mixing bowl, casserole, saucepan, soup bowl, glass / |___ flat / plate, chopping board, frying pan /___ function OR{___ preparation { mixing bowl, plate, chopping board {___ cooking { frying pan, casserole, saucepan {___ dining XOR |___ for food | plate, soup bowl, casserole |___ for drink glass
At this point, each object can be represented by a unique path(s) in the hierarchy and thus by a term in the knowledge representation grammar (KRG). The KRG term is built up using '/' for AND branches, '()' for XOR branches and '{}' for OR branches, similar to the diagram. For example, we could refer to the plate as
The production of a simple taxonomy, or a TDH, for actions is similar to that for objects. Imagine we have a list of specific actions which may occur in a kitchen: beating, mixing, pouring, frying, boiling, baking, eating and drinking. We may look at these and start to build a hierarchy. For example, we may use the same classes: preparation, cooking and dining as we did for the objects:
kitchen job OR
|___ preparation
| beating, mixing
|___ cooking
| frying, boiling, baking
|___ dining
pouring, eating, drinking
processed in 0.003 seconds
|
| |
|
HCI Book 3rd Edition || old HCI 2e home page || search
|
|
| feedback to feedback@hcibook.com | hosted by hiraeth mixed media |
|
| |