Figure 15.7 -The use of task analys

Figure 15.7
-
The use of task analysis as part of the discipline of HCI is somewhat different, but training is still an important application.
-
The hierarchical structure of HTA can be used to structure manuals or course material.
-
For example, we want to write a beginner’s manual on tea making based on the hierarchical task analysis in Figure 15.4.
-
We base each page on one level of task decomposition and its associatedplan (Figure 15.7).
-

This kind of ‘how to do it’ manual is often useful for initial training, but for structuring a course, or for more advanced training material, a more conceptual structure is better.
-
This is precisely where the knowledge-based techniques are strong.
-
The taxonomic structure can be used directly; for example, our course on cars may start with a lecture on steering controls, then have a lecture on controlling the engine speed and gears, etc.
-
This is most likely to be useful when the taxonomy is a strict either/or tree.
-
More generally, we can produce the shortened list of generic objects and actions by ‘cutting’ the taxonomic tree, and use these as the structuring principle.
-
Given such a ‘cut’ of the taxonomy of kitchen tools and jobs in Section 15.4, we may structure a cookery course as follows:
-
Cookery in eight easy lessons.
-
In addition to teaching totally new material, task analysis can be used to help a user transfer from one system to another.
-
Assuming we have performed a task analysis of both systems, a comparison of these will highlight areas for training.
-
A simplecomparison of functionality is notsufficient as the crucial differences may be in procedures.
-
On the other hand, two systems may seem completely different in terms of detailed commands and presentation, but have similar high-level concepts or similar patterns of use.
-

These common features should be brought out and can be used to help the user transfer knowledge from one system to another.
-
15.7.2 Requirements capture and systems design
-
Task analysis can be used to guide the design of new (although possibly not novel) systems.
-
Recall (from Chapter 6) that requirements capture is the process of eliciting what a new system should do.
-
Task analysis in itself is not a form of requirements capture as it refers to the existing system, not the planned system, and it includes many elements which are not part of the system.
-
However, it makes a strong contribution toward the complete statement of requirements.
-
Typically, the original statement of requirements given by a client will mention the new elements required and possibly refer to the existing systemand its functionality.
-
Further information elicited by a system developer may well concentrate on what the system should do but may forget how it will be used.
-
The task analysis of an existing system can help in two ways. First, the analyst can ask ‘Which of the existing objects, tasks, etc., should be in the new system?’.
-
Secondly, the formalized presentation of the existing state of affairs may help the client to clarify what the novel features are to be.
-
It may be decided to automate whole tasks or roles, or simply specific subtasks.
-

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.
-
We may also make some predictions about the use of the new system.
-
Given the parts that are to be included and the planned behavior of the system, we may see how
this will interact with existing procedures, including how information will move in and out of the new system.
-
Some of the procedures may be able to continue as before, especially if the system has been designed to mimic the old, possibly nonautomated, system, but some may need to be retaught completely.
-