![]() | MSc-IT Study Material June 2010 Edition Computer Science Department, University of Cape Town | MIT Notes Home | Edition Home | |
You should have a HTA description that describes hierarchies and plans for this task. You can compare this HTA with the handwriting one to identify the important ways in which the task has been changed when it was computerised. Which tasks have been changes substantially for example, made much longer or shorter, or with a different order of subtasks?
One of the purposes for HTA is to help design task structures that seem as natural as possible to users. One aspect of this might be to retain as much as possible that is already familiar to users; another might be to avoid unnecessary additional tasks.
Adaptations are likely to include structural changes: for example, should each user have their own printer? Should printers have a special facility for printing labels, or even envelopes, without manual intervention?
The word-processor taxonomy is likely to include labels as well as envelopes, owners of printed sheets as well as letters, and printers instead of pens. The multiplicity of printers with different names might be a design issue, as might the kinds of things that can be printed (printable items?). There are more design issues to be discovered!
You should have listed some actors (a particular type of object) and actions they perform. You should have some events (such as 'when the letter has been printed'). You should have some action-event relations (e.g. the label must be put in the manual feed tray before it can be printed). For all the types of relationships, see if you can find at least one relationship in this word processing scenario.
By now, you have probably worked on this letter-writing task as much as you can face. Don't spend too long on this; what matters is that you are starting to get a feel for what is involved in conducting an ER analysis, and how it can help you understand more about the task domain.
This statement is false. Cognitive Task Analysis techniques focus on the details of what is going on in the head and small-scale actions. GOMS is an example of a CTA technique. It has the same type of hierarchical structure as HTA, but has selection rules instead of plans.
HTA, like any task analysis, start from data about how people perform tasks. This data may be gathered by observation, interview, or by reading documentation.
Construction involves structuring and re-structuring the description (hierarchy and plans) to make it as meaningful and useful as possible. Stop expanding description when it is not useful to expand it further.
There are many possible answers to this. The following is just one example.
0 process orders
1 process one order
1.1 receive order
1.1.1 note pizza requirements
1.1.1.1 note toppings required
1.1.1.2 note price
1.1.1.3 add to bill
1.1.2 note additional requirements (e.g. drinks)
1.1.3 note name and address
1.1.4 take payment details
1.2 make pizzas
1.2.1 make a pizza to correspond to one order
1.2.1.1 prepare dough
1.2.1.2 add toppings as specified
1.2.2 put pizzas in oven
1.2.3 wait until pizzas cooked
1.2.4 remove pizzas from oven
1.2.5 put each pizza in a box
1.3 deliver pizzas
1.3.1 give pizzas corresponding to one order to delivery motorcyclist
1.3.2 give bill and address to motorcyclist
1.3.3 wait
1.3.4 check payment received against bill and clear account
Plan 0: do 1 repeatedly (possibly in parallel)
Plan 1: do 1.1 – 1.2 – 1.3
Plan 1.1: do 1.1.1, 1.1.3, 1.1.3 and 1.1.4 in any order
Plan 1.1.1: do 1.1.1.1 – 1.1.1.2 – 1.1.1.3
Plan 1.2: do 1.2.1 repeatedly until order complete, then 1.2.2 – 1.2.3 – 1.2.4 – 1.2.5
Plan 1.2.1: do 1.2.1.1 – 1.2.1.2.
Plan 1.3: do 1.3.1 and 1.3.2 in either order, then 1.3.3 – 1.3.4
KB analysis is concerned with hierarchies of objects and actions, and classifies items in terms of relationships such as class membership, attributes, and features (using AND, OR and XOR relationships).
True. One way to structure a manual would be in terms of related actions or concepts, and KB analysis would help with this conceptual structuring.
Entities include objects (concrete, composite and actors), attributes, actions and events. Note that there are many other terms (e.g. patient, agent, instrument) that are not entities in their own right, but are terms that define a relationship between entities. (If this is not immediately obvious to you, think hard about it).
Task analysis focuses on domain entities, whereas ER analysis for database design focuses on the entities that are to be represented in the resulting computer system.
Objects have attributes. Actors perform actions. Composite objects comprise (simpler) objects. Objects are located at objects. Actions have patients (objects), actors (objects) and instruments (objects). Actions may take place before events, be triggered by events, or caused by events.
In designing your HTA, you will probably have included both searching and browsing as activities. The design consideration is likely to focus on browsing, and on how that can be made efficient and effective.
Note that actions should not be described at the level of a button-click, but at the level of something that has some domain significance. Similarly, objects should not be described in terms of icons, but in terms of objects that have some domain significance. Depending on which sites you choose, you may or may not be able to use your informal analysis to propose some design improvements to the sites.