posted by Thom Holwerda on Sun 11th Nov 2007 15:52 UTC

Mode errors; Preventing mode errors; Conclusion
Mode error

Modality in user interfaces (from "dumb" machines to computers) is the cause of a lot of problems in human-machine/computer interaction. Did you ever wonder why we tend to use "^$&@^%&%" to illustrate curse words? According to Jef Raskin: "'It is no accident that swearing is denoted by #&%!#$&', writes my colleague, Dr. James Winter; it is 'what a typewriter used to do when you typed numbers when the Caps Lock was engaged'." The caps. lock key is a continuous source of irritation and annoyance, as anybody who regularly IMs or emails will understand. The problem with the caps. lock key specifically is that the screen generally does not give any hint as to whether or not the key is activated; sure, there is an LED indicator, but that one is located on the keyboard, far away from the area of focus (the screen). The subsequent errors are what we call mode errors.

Computer usage is filled with mode errors. To get back the example of the power switch: the computers at my faculty have really, really small and illegible LED power indicators, meaning you wonder regularly if the device is on; is it sleeping? In order to wake it up, you move the mouse around, you hit some keys on the keyboard, only to realise the darn thing is still switched off. This is also a mode error.

Another particularly irritating mode error is that of the focus stealing window or dialog. You are typing something somewhere, and suddenly, a window or dialog steals focus, and you continue typing in that new window or dialog; you could be hitting the letters "y" or "n", affecting the outcome of a dialog window before you even get the chance to read it.

Not all mode errors are instantly obvious. Microsoft Excel '98 for the Macintosh had a very interesting mode error (fixed in later versions), that really illustrates how far reaching apparent subtle mode errors can be. If you had a cell in an Excel spreadsheet in cell editing mode (you were typing in it), you could not close that particular spreadsheet's window with the titlebar's close button; you could only close it with the close option in the file menu. If you were in navigation mode (switching between cells), there were no problems.

The problem stems from the fact that in Excel, you need to "close" an editing operation by hitting the enter key; however, reaching the last item on a list already feels like closure from a user point of view, and as such, you feel "done" - the system (Excel), however, has not had any closure at all (it did not register an enter key press) and consequently, Excel still believed you were in editing mode, and disallowed destroying the window, preventing you from destroying any valuable cell input - the fact that you could still close the window via the file menu was probably a bug or slip-up.

Preventing mode errors

The Excel case as described above was not only caused by modes in itself, but also because Excel violated a rule concerning modes: there must be a clear indication of the mode the system is in; Excel lacked this. A blinking text cursor was the only indication within the user's visual focal point (assuming you even knew the window controls would fail in editing mode in the first place).

Paint programs use the mouse cursor to indicate the mode the program is in. When you have the pencil tool activated in Paint.Net, for instance, the cursor changes into a pencil. When you want to draw a square, the cursor changes to a cross-hair with a square in the top-right corner, and when you use the paintbrush, the cursor is just a cross-hair (?). Since the focal point of a paint program is usually the mouse cursor, this works surprisingly well (far from perfect, though).

So, one solution to prevent mode errors is by clearly indicating to the user what mode they are in - however, this is not a solution to the problem of modes; it just tries to lessen the blow. A second, much more far-fetching approach, is to implement so-called user-maintained modes.

A perfect example of a user-maintained mode is the shift key. When the shift key is pressed, the computer switches modes in a similar way to the caps. lock key, but unlike the latter, upon release, the mode reverts back to the original state. This is what is called a user-maintained mode because the user needs to actively keep the computer in the desired mode. Obviously, this makes the user clearly aware of the fact that the system is in a certain mode. Scientific research has shown that this solution actually works (see Sellen, Kurtenbach, Buxton, for instance). Jef Raskin christened this type of modes "quasimodes", or, for the Latin-impaired, "almost modes". Whether it is desirable from a physical point of view (think repetitive strain injury) remains to be seen, though.

User-maintained modes also underlay one of the prime features of today's graphical user interfaces: drag and drop, whose invention is attributed to Jef Raskin (who else). Copying and pasting in the Xerox PARC world happened in a "click-move-click" fashion, a strictly modal way of doing things. Raskin found this cumbersome, and consequently, came up with a drag-and-move way of copying and pasting - effectively a quasimode, because the user has to maintain the clicked state of the mouse button in order to continue the operation.

Conclusion

When designing a user interface, try to keep the amount of modes to a minimum, or, better yet, design your interface in such a way that modality can be discarded completely; adhere to the concept of modelessness. This is easier said than done, of course, but from a usability point of view, this is a very desirable course of action. Reducing the amount of mode errors when using your interface should be a prime goal.

Where the use of modes is inevitable, try to either give the user clear clues as to the mode your computer is in, or try to resort to quasimodes or user-maintained modes if this is a possibility (think of RSI issues with this one, though).

On a final note, do not use modal dialogs or windows. They are evil.


If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
Table of contents
  1. Modes
  2. Mode errors; Preventing mode errors; Conclusion
e p (0)    29 Comment(s)

Technology White Papers

See More