Figure 1. trying to close the window
Human-Computer Interaction 3e Dix, Finlay, Abowd, Beale
I was in the middle of a lecture and just finished assigning students to groups. An Excel spreadsheet had all the student names and against each name I added a column with the groups A, B, C etc. After finishing I tried to close the spreadsheet by clicking the close box at the top left of the window (see figure 1 - Mac OS window). I clicked and nothing happened, tried again and again ... still no response. Eventually I though the application had crashed and was about to attempt to kill it when I tried the File menu and found that it did work and was able to close the window that way.
Figure 1. trying to close the window
The fact that the File menu worked suggested it was not an application crash, but in fact something wrong in the logic of the interface. After attempting to reproduce the error it became clear what was wrong. Excel has various modes of which two of the main ones are:
I was actually in cell editing mode and in this mode Excel does not allow closing the spreadsheet through the close box (but does allow this through the File menu!). I was actually still in the middle of editing the last cell I'd changed and needed to confirm this by hitting the 'return' key which would have taken me back into navigation mode (figure 2) from whence I'd have been able to close the window normally.
Figure 2. Excel navigation mode
|
N.B. there are actually many more modes including various dialogue boxes and also sub-modes of cell editing. In particular the behaviour whilst editing contents of plain text/number cells is different from that during the editing of formulae cells - clicking another cell in the former mode implicitly moves into navigation moide whereas during the latter adds the cell contents to the current formula. |
So was I being particularly dull not realising that I was in the wrong mode. Actually many Excel users probably never even realise that there are different modes, often things work fairly seamlessly - so long as you hit return/enter after entering or editing cell contents!
However, Iwas aware of the different modes, so was it possible for me to tell that I was in the wrong mode?
In fact yes, there are two main indications of editing mode. Compare Figure 1 and Figure 2. In the former the cell editing area at the top has a cross and tick to the left of the = sign. Also in the cell itself a text cursor is blinking. These differences are highlighted in figure 3.
Did you notice these differences between figure 1 and 2 without them being pointed out?
The second of these differences which is potentially most noticable as it involves a blinking cursor, was towards the bottom of the real spreadsheet screen (it has been drawn on a smaller screen here to make it possible to see all critical things at once). Really it is only the cell edting box that was at all near my visual focus at the point of the error.
So, although there are visual distinctions in the modes, they are slight.
Figure 3. visual indications of mode
The modes in Excel are quite well designed in that the changes are mainly implicit and users are often not aware that they are there Excel does the 'right' thing even though that thing varies depending on circumstances. For example, typing anything whilst in navigation mode implicitly changes one into editing mode and hitting the enter key (natural to do when you've finished typing something on a computer) takes one back into navigation mode..
So, what did I do wrong?
Answer number one is I didn't hit the return key after entering the last group.
But why?
The answer is closure. I was typing the individual groups and using the return/enter key to move down the column, but when I entered the group letter for the last student I got that 'Aha - I've done it' feeling - closure. So inside I felt I'd finished entering the groups, but Excel was not 'finished' as it needed the extra enter key.
This is a classic problem - we have a computer action that requires an arbitrary ending action (in this case pressing the enter key) that is not necessary from a pure task point of view. In such cases closure errors are to be expected.
So is this an unfortunate error -just one of those things, or is it something that could have been addressed at the design stage?
Well first of all it is not clear whether this behaviour is a deliberate design decision or not. There are good reasons to forbid closing the spreadsheet while a cell is being edited - do you want the edited version of the cell or the original one? However if this is a deliberate design decision, why is it allowed from the File menu. This and the lack of any sort of error message suggests this this is simply an omission!
So we have two problems:
The first is an example of 'the bits leaking out' (see my lecture notes on 'Deep Within - event-driven interfaces'). Infering internal code from behavious is always a little dangerous, but it probably does somethjing like this ... There is a single handler for the top menu that is always active, but mouse clicks are channeled to different event handler depending on the mode. The handler for the edit mode then simply igbnores clicks in regions it doesn't care about - like the top bar of the window. Possibly the person coding the edit-mode handler deliberately decided to igore the close action (a design decision) or may have simply not noticed it was a possibility (code/testing error). Either way the design decision was either not made at an appropriate level or it was made and not tested.
Let's look now more broadely at the modes within Excel.
General design advice for modes is either:
As we've already discussed, modes are often necessary and Excel has tried to make them not too intrusive for the user. The lack of strong visual indications is part of this process of making the interaction seem natural. When we have conversations with one another we are constantly using and interpreting words that have meaning within context and Excel is effectively doing that.
However, the inevitable consequence of making modes of low salience is that mode errors will occur. The 'close box' is not the only such error. For example, typing anything in navigation mode moves you into editing mode and starts to overwrite the cell contents. So, if you have selected a cell and can see the formula '3+5', you may simply type '+2' thinking mitskenly that you are in cell editing mode. However this has the effect of deleting the original cell contents rather than getting '3+5+2' as probably intended. If the user is looking at the screen this error will be imediately apparent and the user can either press the cross to cancel the edit or use 'undo'. If however (remember this is a a spreadsheet) the user is looking back and forth to a paper list of numbers, it would be quite possible not to notice the error. Also once the formula has been confirmed (with the enter key) the formula will no longer be visible, just the result, further reducing the likelihood of later noticing the error.
So modes are there, not very visible, and they matter!
Perhaps this error is the price we pay for the power of Excel. However, there are design options that may help. many years ago, Andrew Monk suggested using different key click sounds and found that this significantly reduced mode error (Monk, 1986). A similar visual effect would perhaps be to add a very slight blue cast over the spreadsheet during cell editing mode (giving the idea of distance/low saliance). Alternatively the interface actions could have been reconsidered to reduce the impact of mode errors. Obviously any such design solution would need to be weighed up against other interface considerations.
This particular problem was a combination of a latent mode error combined with user's premature (from a system viewpoint) closure.
The fact that mode errors could occur is predictable given the relatively low salience of the modes, and there are several potentially serious errors that can occur due to this problem.
The mode problems were compounded by an obvious slip-up during design or coding. This is evident as the ability to close the sheet during editing mode depends on which interface methods is useed to access this underlying system function.
Alan Dix, 2001