Human-Computer Interaction 3e Dix, Finlay, Abowd, Beale

exercises  -  11. user support


Write a manual page for making a cup of coffee. Assume your user has no experience but will recognize a cup, a kettle, a spoon, etc. Swap your manual with a partner. Does your partner's manual give you sufficient instruction to make the cup of coffee? Discuss improvements with your partner and agree on a final version of the manual.


First you have to decide upon the level of granularity at which you are going to work. The aim of the exercise is to demonstrate that it is not as straightforward as it might seem to provide instructions even for a very familiar and well-understood task. Given this, it is most helpful to assume that the user knows very little. The example solution (Table Ex11.1) assumes that the user will recognize objects (perhaps they are labelled) and understands common actions and directions, but not the specific actions required here. Alternatively you could choose to assume that the user does know how to turn on a tap and open a jar.

N.B. The two options could be expanded further if required. Other alternatives could be included, such as getting water from another source.

Table Ex11.1 - Coffee making manual
Manual for making a cup of coffee
Required: an automatic electric kettle, a jar of instant coffee powder or granules, a mug, a teaspoon, a mains water tap (or an alternative source of water), a mains electricity supply, milk (optional), sugar (optional).
CAUTION: Electricity can be dangerous - avoid any contact between electric connections and water.
Boiling water can scald - take care.
To boil water: Ensure plug on kettle is not connected to mains electricity supply.
Remove lid from kettle.
Place kettle directly beneath spout of tap.
Turn tap handle anticlockwise to release water.
When water reaches mark labelled 'full' on kettle turn tap handle clockwise to close off water supply.
Replace kettle lid.
Move kettle to proximity of mains electricity supply.
Place kettle's plug into electricity socket.
Press button marked 'on' on top of kettle to switch kettle on.
When the water has boiled, the kettle will switch off automatically and the 'on' button will return to its original position with a click.
Remove kettle's plug from electricity socket.
To make coffee: Take jar of coffee and remove lid by turning anticlockwise.
Fill teaspoon with coffee.
Place contents of teaspoon in cup.
Replace lid on coffee jar and turn clockwise to tighten.
Pour boiling water from the kettle into the cup up to approximately 1/2 an inch from the top.
Add milk if required (to almost fill cup).
Add sugar if required.
Stir coffee mixture with spoon.
The coffee is now ready to drink.

The discussion should focus on the assumptions that are made. You should make a conscious decision about what assumptions to make, rather than making them by default. This should ensure that the assumptions that are made are appropriate to the particular user.

You could also contrast your answers here, based on the material in this chapter, with the 'making tea' manual in Chapter 15. How useful do you feel task analysis is in designing a manual?



Find a computer application that you have never used before. Attempt to learn to use it using only the online support. Is there enough information to allow you to use the application effectively? Is the information easy to find? What improvements (if any) would you suggest?


This is an investigative exercise for which there is no example solution. Possible systems to consider would be a word processor (for example, Microsoft Word, Publisher, Appleworks), a graphics package (Adobe Photoshop, Macromedia Freehand, Paintshop Pro) or a spreadsheet (Excel, Lotus). It may be helpful to have a list of tasks to learn to perform using the application. Include in this list basic tasks (creating a document, spreadsheet, etc.) and more complex ones (creating templates, etc.). The aim is to think about the provision of help from the point of view of the solitary user trying to figure things out alone. You should therefore make explicit any prior knowledge you use to help interpret the system (for example, experience of similar systems).



What knowledge is needed to build an adaptive help system? Which do you think is most difficult to provide and why?


It requires at least knowledge of the domain and knowledge of the user. It may also require knowledge of teaching strategies and tasks. Knowledge of the user is usually most difficult to provide, along with knowledge of the task. Even if the user can be monitored, interpreting the user's behaviour in anything other than coarse terms is difficult without access to his thought processes. However, this level of interpretation, and generalization, can be helpful nonetheless (for example, a record of what the user has already done successfully or how often he has used the application). Context can be deduced from the user's current activity. This too can be difficult to determine, however, unless it is a simple case where the tool in use indicates the activity being performed.

Domain knowledge in the general sense is probably the easiest to provide (although it is time consuming to do so). It is available within the system itself or from the designer.



Look at as many online support systems as you can. Which do you find most useful and why? Try to assess them using the requirements discussed in Section 11.2.


This is another open investigative assignment. The set of requirements in Section 11.2 should provide students with a structure for evaluating the systems. A scoring system can perhaps be worked out to aid comparison. Try to compare a general context-sensitive help system with an application-specific one. A hypertext-based help system would provide an interesting contrast, as would a manual-based help system (such as UNIX man) and a prompt-based one.



Using your library facilities and the world wide web, investigate the benefits and limitations of adaptive help systems. What examples of adaptive and adaptable help are available and how useful are they?

answer available for tutors only

Open-ended research question, which should discuss the range of provision available, from full expert system technology to the role of wizards and agents, cues and context-sensitive help, drawing on examples found.



What are the four main types of help that users may require? For each type, give an example of a situation in which it would be appropriate.

answer available for tutors only

The four main types:

Quick reference is used primarily to remind the user of details of tools he is familiar with and has used before. For example, to find a particular command option, or to check the syntax of the command.
Task-specific help is required when the user has encountered a problem with a particular task or is uncertain how to apply the tool to his particular problem. Help offered is directly related to the task. Example would be the application 'wizards' that guide you step by step through a common task such as mail merge.
Explanation: More experienced or inquisitive users may want a full explanation of a tool or command to enable fuller understanding. Explanation will probably include more information than needed.
Tutorial help is particularly aimed at new users of a tool and provides step-by-step instruction (perhaps by working through examples) of how to use the tool.

Each of these types of user support is complementary - the same user may require each at different times. Interested students may like to investigate 'just in time training' in which training is supplied when it is needed - a sort of mixing of task-specific and tutorial help.



Which usability principles are especially important in the design of help systems, and why?

answer available for tutors only

Availability - the user needs to be able to access help at any time during his interaction with the system, and should not have to quit the application he is working on to open the help application. In windowed systems, the help application can run concurrently with any other application.
Accuracy and completeness - as well as providing an accurate reflection of the current state of the system, help should cover the whole system. The designer cannot predict which parts of the system the user is going to require assistance with and must therefore assume that all parts must be supported.
Consistency - help systems may incorporate a number of parts, and the help provided by each must be consistent with the others and within itself. On-line help should also be consistent with paper documentation in content, terminology and style of presentation. Consistency itself can be thought of as a means of supporting the user since it reinforces learning of system usage.
Robustness - help systems are often used by people who are in difficulty, perhaps because the system is behaving unexpectedly or has failed altogether, so the help system itself should be robust, with correct error handling and predictable behaviour.
Flexibility - many help systems are rigid, producing the same help message regardless of the user's expertise or context of work. A flexible help system will allow each user to interact with it in a way appropriate to his needs.
Unobtrusiveness - the help system should not prevent the user from continuing with normal work, nor interfere with the user's application.

For more tutorial-style help the designer may need to consult with educational experts so as to adopt an appropriate learning paradigm for the material.



Describe some of the different approaches to providing user support systems, with examples.

answer available for tutors only

Command assistance - the user requests help on a particular command and is presented with a help screen or manual page describing it. This is the approach used in the UNIX man help system and the DOS help command.
Efficient only if the user knows what he wants to know about, which is often not the case. Deals well with commands which the user is aware of but uses rarely.
Command prompts - provide help when the user encounters an error, usually in the form of correct usage prompts. Useful if the error is a simple one, such as incorrect syntax, but assumes some knowledge of the command.
Context-sensitive help - range from those with specific knowledge of the particular user to provision of a simple help key or function that the system interprets according to the context in which it is called. Often used in menu-based systems to provide help on menu options, e.g. Macintosh Balloons help or tooltips.
On-line tutorials - allow the user to work through the basics of an application, progressing at his own speed, experimenting with small examples, and repeating parts of the tutorial if needed. Most on-line tutorials know nothing about the user's experience or the domain, so are inflexible and often unforgiving.
On-line documentation - parallels the paper documentation and makes the material available continually in the same medium as the user's work. Disadvantage is that large manuals may be less appropriate on-line than on paper. The large amount of information contained in manual pages can create problems for the user by 'masking' the information they are seeking, so on-line documentation is often used by more expert users as a resource or reference.



Applications are often supported by an online version of the paper documentation; in some cases there is no paper documentation at all.

What are the advantages of online documentation? What are the disadvantages, and how can they be overcome?

answer available for tutors only

Advantages: the material is available continually (assuming the machine is running!) in the same medium as the user's work and, potentially, to a large number of users concurrently. Paper manuals get lost easily, are constrained to one physical location, and are often somewhere else when you want them. On-line documentation is one way of avoiding these problems. Often on-line documentation is searchable by keyword (not a substitute for a good index!) and may include hypertext links including links to external electronic sources such as the web.

Disadvantages: people prefer reading text on paper than on a computer screen. Cues used in browsing paper documents, e.g. indexing, contents and page numbering are not always reproduced in electronic documentation systems.

The amount of information can in itself create problems for the user (though this might also be a problem with a paper document). The detail 'masks the information the user wants to find. On-line documentation may be more suitable for expert users as a resource or reference than for less experienced users.

Overcoming disadvantages: breaking the documentation into clear logical sections; providing a summary of the key information prominently, with further information available if required; using hypertext techniques; minimal manuals.



Discuss the presentation issues involved in the design of effective and relevant help systems.

answer available for tutors only

How help is accessed by the user:

How help is displayed:

Appropriate presentation style depends on level of help being offered and space it requires, e.g. inappropriate to open a manual page line by line, or take over the whole screen to give the user a hint.

Some active help systems provide visual cues when they have a suggestion to make (for example, an icon may be highlighted) - the user has the option of taking the suggestion without having to abandon or interrupt his work.

How help is made effective:

Like interfaces, help screens/documentation should be designed taking into account the capabilities and task requirements of the user. Whatever the technology used, principles for writing and presenting it effectively are the same: use clear, familiar language, avoiding jargon as much as possible; terminology should be consistent between paper manuals/tutorials and on-line support material; help systems should tell the user how to use the system rather than simply describing it and not make assumptions about what the user knows. Documentation, which fully describes the system's functionality as well as instructing how to use it, should present both instructional and descriptive information clearly and accessibly.

Physical layout of documentation affects usability, e.g. blocks of text are difficult to read on screen. It can be broken into clear logical sections, or organized as a hypertext. Information can be arranged hierarchically. with each layer in the hierarchy providing increasing detail. Indexes can be used to show available topics, and can be organized to reflect the functional relationships between the subjects as well as their alphabetic ordering. Consistency of format also important, so that different types of information, e.g. definitions, examples, instructions, are recognizable.

Individual exercises

ex.11.1 (ans), ex.11.2 (ans), ex.11.3 (ans), ex.11.4 (ans), ex.11.5 (tut), ex.11.6 (tut), ex.11.7 (tut), ex.11.8 (tut), ex.11.9 (tut), ex.11.10 (tut)

home | about | chapters | resources | exercises | online | editions | interactive | community | search | plus +++
exercises: 1. human | 2. computer | 3. interaction | 4. paradigms | 5. design basics | 6. software process | 7. design rules | 8. implementation | 9. evaluation | 10. universal design | 11. user support | 12. cognitive models | 13. socio-organizational | 14. comm and collab | 15. task models | 16. dialogue | 17. system models | 18. rich interaction | 19. groupware | 20. ubicomp, VR, vis | 21. hypertext and WWW