Context Error: Problem Solved?

Context error is a natural consequence of the design of the command line style of dialogue, since, typically, the user may type in any command

and it is only evaluated when the re tu rn key is pressed. In the WIMPS interaction style, it is possible in many cases to preclude the incidence of context error by 'ghosting out', hiding or removing menu items and icons which have no valid function in the current context or relate to non-existent 'objects'. To some, this may appear to be an adequate solution to the problem. However, this approach may be misguided for a number of reasons.

Firstly, this approach can only be adopted for menus and icons; simply disabling keys amounts to a 'do nothing' approach which suffers the second disadvantage which is that the approach constitutes a bar on exploration; context error may be caused by a lack of knowledge of the preconditions for an action and making the action impossible in certain circumstances does nothing to correct this. In this case, it treats the symptom and not the cause. This argument should not be confused with the positive effects on learning which have been achieved by preventing users from accessing advanced features of an application; the so-called 'training wheels' approach (Catrambone & Carroll, 1987). That approach does not relate to contextual features, in terms of system states, but removes options for the whole of a period of time. The 'ghosting' approach removes options on the basis of current system states during the course of a single interaction. The idea that is being promoted in this thesis is that the user’s ability to build and maintain a good mental model of a system is enhanced by the system's

support of users' exploration of the system in the pursuance of their prevailing goals and plans. This idea challenges the 'ghosting' approach but is neutral with regard to the 'training wheels' approach.

Thirdly, there is evidence to support the view that errors enhance the

conceptual model of a system. Frese et. al. (1991) found that error-based

training produced better non-speed performance and free recall than

error-avoidance training. Lastly, learning is an active process and is

enhanced by interactivity as opposed to factual presentation (Carroll & Mack, 1984: p. 292).

productive, since substantial benefits may attach to the possibility of making errors. Not being able to do things wrongly does not imply the ability to do them correctly. A user’s conceptual model may be such that he or she would make a context error if it were possible to do so and merely rendering it impossible does nothing to correct that model. These practices could be improved in this respect if, for example, selecting ghosted items provided an explanation of why the option is not operative in that context. (This being functionally equivalent to allowing the error to occur and then providing help). However, this would not be applicable in circumstances, for example, where items are removed from the display, as in the case of deleted files. The graphical user interface philosophy does not allow the speculative action which could give the system information about user requirements or intentions.

These arguments lead us to conclude that context error is not a function of particular interface styles but cuts across these distinctions. It also seems clear that direct feedback mechanisms in the interface are inadequate to enable a user to build and maintain an appropriate conceptual model of the system. After all, there will always be more information concerning system states and functions than it is possible or desirable to present to the user at one time. Even if it were possible to somehow cram everything onto the screen, the user will normally be interested only in the information relevant to his or her current concerns. The problem is in finding a way of determining what is relevant. It seems unlikely that this will turn out to be a static specification or one which can be generated from a static set of criteria. This being the case, what is sought is some interface component whose function it is to determine dynamically the information to which the user should have access.

Error situations constitute an ideal opportunity to provide relevant online help and there are a number of reasons for this. Errors themselves provide the help system with information concerning current user goals and possible deficiencies in the user's model of the system. Information can be presented in terms which relate to the user's current interestsj rather

than as abstract descriptions of the system; the user's work can be put at the centre of concerns in the form of the objects and operations involved in the user's current task (Carroll & Mack, 1984: p. 294). Consequently, the information will be more digestible because it concerns issues on which the user is already focussed. Issues affecting the appropriateness of different forms of user support and the requirements that they impose, in relation to the current focus of context error are taken up in the following two chapters.