HUMAN-COMPUTER INTERACTION
SECOND EDITION
HUMAN-COMPUTER INTERACTION
SECOND EDITION
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
Notice that the tree has been drawn using the characters: '/|{'. These are a characteristic of TDH and represent AND, XOR and OR branches respectively. The explicit labels AND etc. are not used in a normal TDH as these are implied by the way the tree is drawn.
Strict application of the uniqueness rule is not always necessary. Other similar techniques cope quite happily without it, but they normally adopt simple hierarchies, rather than the more complex AND/OR/XOR TDH trees.
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
Looking back and forth between the objects and the actions will suggest omissions or restructuring on one side or another: What action do we do with a chopping board? Clearly we should add chopping as an action. The action of baking may suggest that we include baking trays and bread tins under the objects. This cross-checking is particularly important for capturing all actions as it is often easier to see what people are using for their job than to work out what they are doing. Furthermore objects are often grouped naturally under their function, so the object groupings may suggest action groupings and vice versa. In addition, we can apply the TAKD uniqueness rule to the action TDH, which would mean performing some more subdivisions, perhaps adding distinctions between those actions concerned with liquids and those with solids.
Notice that the KRG terms do not use the complete KRG description of each action and object, but instead opt for a generic description. Choosing the
However the classification and production of hierarchies is performed, the job of producing possibly large taxonomies and hierarchy diagrams is not trivial. This can be done by hand on paper or using a standard word processor, but is easier if an outliner is used. There are several commercial outlining tools which can be used, and most word processors and many spreadsheets have outlining facilities. These outliners make it easy to shift partially sorted groups as we refine the classification. They also allow us to hide unwanted information, say when we want to look at the top levels of decomposition of a task hierarchy, or if we want to 'cut' a TDH taxonomy to look at generic objects or actions.
As the high-level design of the system progresses, task analysis continues to play a role. The structuring provided by, for instance, TDH taxonomies can help the designer to choose an internal model for the system which matches the existing expectations of the users. This may, of course, be modified to accommodate novel features, but gives a reasonable first structure.
In a similar manner to the manual design, taxonomies of tasks or objects may be used in the design of menus. The TDH trees are obviously most useful in this respect. Top-level menus can be labelled after the top-level decomposition and submenus after the next level, etc. For this, the tree may be first reduced to a simple either/or tree, thus guaranteeing that each object/action is under exactly one menu. Alternatively, more complex trees allowing AND and OR as well as XOR branches can be used. In this case, an object/action may be found by several paths through the menus.
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 |
|
| |