Error Messages

The question of the form and wording of help or error messages has not been discussed, while it is acknowledged that this is at least as important an issue as misconception diagnosis. There is little point in being able to automate the detection of user misconception if the user is unable to assimilate the resulting messages. It has not been the aim of the present research to investigate or present recommendations for this aspect of automated help systems. However, it has been stressed that information should be presented in terms related to the user's current concerns. That is to say that reference should be made by name to the objects involved in the error and to the action associated with the command involved. For example: "You cannot delete the file 'myfile' because its parent directory 'mydir' was write protected earlier in this session, (command was: chmod mydir 000)".

No definitive substantiation of the related claims that, a) errors can be beneficial and b) the preclusion of errors has negative effects on learning, has been made. Instead, an attempt has been made to persuade the reader of these points by argument. It is considered that the possibility of providing conclusive evidence for these claims is fairly remote and well beyond the scope of this research. However, the thesis presented here does not rely on their veracity, in as much the approach it advocates is perceived to be an effective one and it is claimed that this is the case, in that it supplies a generalisable method for rendering any human-computer dialogue more cooperative with regard to dialogue responses in a class of situations of user error.

8.4 Possible F u rth e r D evelopm ents

Apart from the application of the current approach to context error to interfaces other than command line format, there are two other areas which could reward further investment of research effort. The first is the strengthening of criteria for misconception diagnosis and the second is the design of a generic implementation of the assistant.

Thus far we have evinced two criteria for the diagnosis of user misconception. Logical proximity is the closeness of a particular possible world to the actual world, in terms of the number of transforming actions separating them. This criterion represents a general principle of conservation of the system state, which has the significance of crediting the user with the ability to track the system state in a mostly accurate manner, as it evolves throughout the interaction.

A possible world is said to be psychologically proximate to the actual world if it differs to it in some respect which, had it not, would rehabilitate the erroneous command. This relates to the user characteristic of distorting the actual world (in terms of the user's mental model of the system) only in ways which make sense, given some error in STM or lack of awareness of the effects of some action.

Thus, these two criteria relate to two of the possible causes of context error, the third cause being unawareness of the preconditions of some action. As yet, we have determined no positive criteria for diagnosing context errors with this cause and have used the lack of evidence under other criteria to indicate this possibility. This is not an entirely unsatisfactory state of affairs. While a context error caused by a failure in STM or lack of awareness of the effects of some action will invariably be reflected by the presence of a particular action in the interaction history, if the cause is a lack of awareness of the preconditions of some action, a causal antecedent action may not be present. However, this cannot be generally relied upon for accurate diagnostic results and some other, positive criterion for assessing the hypothesis of this cause would be welcome.

The only available source would appear to be some measure of user expertise, gained by monitoring user behaviour in the course of the interaction. One such method would keep counts of successful and unsuccessful uses of commands and precondition violations and use these to construct a representation of user expertise across the functionality of the application. This would, of course, need to be a dynamic user model, capable of responding to the user’s gain in and loss of expertise over time.

If the Prolog clauses constituting the UNIX® simulation described in Chapter 6 are read declaratively, they can be seen as a functional description of (part of) the UNIX® file system. Given this functional description, a command input, a system state and an interaction history, the analyser will produce diagnoses of user misconception and generate appropriate help messages.

As it stands, the analyser is tied to the particular application but this is not a necessary condition. The analyser could be made to generate its hypotheses of user misconception via the functional rule-base defining the system, since all causal relations between commands and their effects and preconditions are represented within it. Thus, there is a distinct possibility of producing a generic assistant which would operate on a rule-base, system state, interaction log and command description to produce misconception diagnoses for a range of applications and, although it has proven to be a non-trivial task (Jackson & Lefrere, 1984), it is also possible that error or help messages could be generated from the rule-base and system state description. It is recognised that this would constitute a fairly ambitious project.