| Alan J. Dix | & | Stephen A. Brewster
|
|
School of Computing
|
Department of Computing Science,
|
You can download this paper as Word 5.1 stuffed binhex.
See also Alan's pages on status-event analysis
This is an unusual paper. Most papers describe how a problem is solved using the authors' methods or design expertise. However, this paper is about how the authors deliberately caused a problem in an interface. This is not as strange as it seems. Being able to cause a normally infrequent problem when required is a good sign that our techniques offer strong analytic leverage. Furthermore, reliably producing a problem is a prerequisite for experiments on methods to relieve that problem.
Our focus is the design of on-screen buttons, and in particular the problem of mis-hits. Consider a typical screen button. The proper use is as follows: (1) the mouse cursor is moved over the screen button, (2) the key on the mouse is depressed which causes the button to highlight, (3) the key on the mouse is released causing the required action to be performed and finally (4) the mouse cursor is moved off the screen button. (N.B. the word 'key' is used for the physical button on the mouse to help resolve the confusion between the screen and mouse buttons). The details of this interaction differ slightly between different graphical toolkits and environments, for example, in ways that the screen button is highlighted. Furthermore, these slight differences can have appreciable effects on the usability of the widget. One particular feature common to many buttons is the ability to back out of the action by removing the mouse from the button whilst the mouse key is still depressed. Unfortunately, with this form of button, the user occasionally mis-hits. That is, it appears as if the button has been correctly hit, but some time later (often much later) it becomes obvious that the relevant action has not been performed. The reason for this problem is that the mouse cursor unintentionally 'slips' off the button before the mouse key has been released. The problem occurs infrequently, but as the error is often not noticed for a considerable time, the effects can be quite serious.
In many interactive systems it is important to handle both events (e.g., user key strokes or system bleeps) and status (mouse position and screen display) (Dix, 1991). The fundamental difference being that event phenomena happen at a particular instant, whereas the value of status phenomena can be sampled at any time. This status/event distinction, augmented with the use of mode, has been used by Brewster, Wright & Edwards (1994) to study the effects of auditory feedback on scrollbar interaction. In Dix, Finlay, Abowd & Beale (1993) the screen button scenario was studied using status/event timeline diagrams. These look at levels in an interactive system (in this case the user, screen, dialogue and application) and look at the changes in status and events that occur. Timelines are then drawn for each entity and the events marked. The analysis focuses especially on the perceived time of events for different agents in the system, and the feedback from events at all levels. The diagrams and analysis are not reproduced here, only the results of the analysis.
This analysis highlights the necessary conditions for the problem to occur: (i) the user reaches closure after the mouse key is depressed and the screen button has been highlighted, (ii) the focus of the next action is at some distance from both the button and the location of the original action and (iii) the cursor is required at the new focus. Because of closure (i), the mouse movement (iii) can overlap with the release of the mouse key giving rise to the mis-hit. This is a form of 'race condition' within the user's nervous and motor system. However, because the attention (ii) is not on the location of the old action, feedback will not be noticed. The problem occurs because the user does not check each action explicitly, and is thus an 'expert slip'. Complete mouse novices have a similar error, but for entirely different reasons, they have trouble with the hand-eye coordination. A solution for the novice problem (e.g., making the buttons bigger) will neither be appropriate, nor effective for the expert slip. Furthermore, expert slips are difficult to discover through experimentation and detailed analysis is one of the only ways to find and solve such problems.
One potential solution to the button problem is to augment the visual feedback with auditory feedback. The intention is not to prevent mis-hits occurring, but to alert the user when they do. The exact form of auditory feedback is determined by the analysis technique, and we wished to design an experiment to investigate the effectiveness of the feedback. The results of this experiment will be reported in a subsequent paper. However, before we could assess the effectiveness of the feedback, we needed to engineer situations when mis-hits would occur. Remember that, like many potentially serious problems, mis-hits are infrequent events. Thus designing an effective experiment is far from trivial.
The first experimental design was a simulated typing task. On-screen was a numeric keypad along with a code display area, an 'accept' button and a 'next' button. The subjects had a (long) list of five digit code numbers, which they had to enter using the mouse and on-screen keypad. After each complete number had been entered, the subjects pressed the 'accept' button and, if the code was correct, pressed the 'next' button to move on to the next code number. A pilot of this experiment was run without auditory feedback on five subjects each working for 20 minutes. This produced no mis-hits. This was disappointing, but not altogether surprising, given the rate of occurrence we had observed in our own use, it would take experiments far longer than the (already very bored) subjects could stand to produce mis-hits. However, we had hoped that the time pressure of quickly entering the numbers would have been sufficient to produce a stress effect.
At this stage, we realised that we had produced the experimental situation without subjecting it to detailed analysis. Recall that there were three conditions necessary for a mis-hit. The first, closure, happens at some degree after most button hits and so is not really subject to manipulation. The keypad is distant from the number entry area (ii) and so application feedback would not be noticed, but because numeric keypad buttons were close together there is no rapid movement to the next button and hence little chance of a race condition. After pressing the next button, the subjects' attention must shift to the next code number to be typed. Thus there is a large change of visual focus, but no requirement for the mouse to move there. Only when the new number has been read will the subjects' eyes and mouse move back to the keypad. Thus there is again no likelihood of a mis-hit. So, if we had applied our analysis properly, we would never even have tried the original design. However, having re-focused ourselves on the analysis, we were able to design a situation which we predicted would cause mis-hits. We simply required that the subject pressed the 'accept' button to confirm every digit entered. Assuming the subject reads the numbers and then types from memory, the focus will move back to the keyboard after each 'accept' hit. That is it will now satisfy all the conditions (i-iii) for a mis-hit. We then predicted that with the speed required of the experiment this new design would indeed cause mis-hits.
The experiment was repeated and our predictions were confirmed. The initial situation produced no mis-hits, whereas with the new design we had as many as 40 mis-hits for a single subject. The rate varied considerably between subjects, but overall effect was dramatic obviating the need for any statistical tests. Examination of some of the mis-hit occurrences showed that it was often several attempted mouse keystrokes later before the subjects noticed that a mis-hit had occurred.
Strong predictions are hard to come by in HCI. It is easy to retrofit an explanation to a problem and feel one has gained insight. Even if subsequent redesign corrects the problem it can be hard to disentangle the analytic technique from the analyst's design insight. However, the techniques we have used have gone beyond such descriptive techniques. Our initial intuitive design failed entirely - in the sense that it didn't cause errors! It was only when we returned to the analysis that we were able to predict the outcome of the original design and design a new one which could predictably cause mis-hits. The difference between the situations which cause error and those which do not is subtle. The ability to generate errors consistently suggests that we have a strong and robust analysis technique.
The work also emphasises the importance of fine details in the design of widgets and low-level interaction. It is often assumed that widgets such as on-screen buttons are all pretty much alike. However, this sort of analysis shows that subtle differences, such as when an action is performed, can make large differences to usability. The button design described here and used in many toolkits, allows the user to back out of potential error situations, but at the expense of causing errors with delayed recognition. This conflict suggests a trade-off, suitable analysis can suggest designs which satisfy both requirements.
S.A. Brewster, P.C. Wright & A.D.N. Edwards (1994). The design and evaluation of an auditory-enhanced scrollbar. In B. Adelson, S. Dumais and J. Olson (Ed.), Proceedings of CHI'94, Boston, Massachusetts: ACM Press, Addison-Wesley, pp 173-179.
A. Dix, J. Finlay, G. Abowd & R. Beale (1993). Human-Computer Interaction London: Prentice-Hall.
A. Dix (1991). Chapter 10: "Events and Status". In Formal Methods for Interactive Systems, pp. 239-270. London: Academic Press.