In user interface design, a mode is a distinct setting within a computer program or any physical machine interface, in which the same user input will produce perceived different results than it would in other settings. The best-known modal interface components are probably the Caps lock and Insert keys on the standard computer keyboard, both of which put the user's typing into a different mode after being pressed, then return it to the regular mode after being re-pressed.

A precise definition is given by Jef Raskin in his book "The Humane Interface":

""An human-machine interface is modal with respect to a given gesture when (1) the current state of the interface is not the user's locus of attention and (2) the interface will execute one among several different responses to the gesture, depending on the system's current state." (Page 42).

An interface that uses no modes is known as a modeless interface^[1]. Modeless interfaces intend to avoid mode errors^[2] by making it impossible for the user to commit them.

Examples

There are several popular examples of software employing modes:

• vi - has one mode for inserting text, and a separate mode for entering commands. There is also an "ex" mode for issuing more complex commands (e.g. search and replace). Under normal circumstances, the editor automatically returns to the previous mode after a command has been issued; however, it is possible to permanently move into this mode using Shift-Q.
• Emacs - has a special mode for issuing commands, which is entered by pressing the control key plus a letter key. This differs from vi in that the mode always ends as soon as the command is called. Emacs also has many "major and minor" modes that change the available commands, and are automatically invoked based on file type to more easily edit files of that type. Modes are written in Emacs Lisp, and all modes may not be included with all versions.
• Cisco IOS - in order to execute certain commands, you must enter a certain "command mode" that allows you to execute that command.
• Also, tools chosen from a palette in photo-editing and drawing applications are examples of a modal interface.

Criticism and mode errors

Modes are generally frowned upon in interface design because they inevitably lead to input errors, known as "mode errors", when the user forgets what state the interface is in, performs an action that is appropriate to a different mode, and gets an unexpected and undesired response.^[3] A mode error can be quite startling and disorienting as the user copes with the sudden violation of his or her user expectations. Interface guru Jef Raskin came out strongly against modes, writing, "Modes are a significant source of errors, confusion, unnecessary restrictions, and complexity in interfaces." Later he notes, "'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'."

Larry Tesler, of Xerox PARC and Apple Computer, disliked modes sufficiently to get a personalized license plate for his car that reads: "NO MODES". He has used this plate from the early 1980s to the present, on various cars. Along with others, he has also been using the phrase "Don't Mode Me In" for years as a rally cry to eliminate or reduce modes. ^[4]

Examples of mode errors

• The most common source of mode errors may be the Caps lock key.

• A frequent example is the sudden appearance of a modal error dialog in an application while the user is typing; the user expects the typed text to be introduced into a text field, but the unexpected dialog discards all that input and may even interpret some keystrokes (like 'Y' or 'N' for 'yes' or 'no') incorrectly.

• The Unix text editor vi can be notoriously difficult for beginners precisely because it uses modes, and earlier versions configured mode indication to be turned off by default.

Workarounds and alternatives

HCI researcher Donald Norman argues that the best way to avoid mode errors, in addition to clear indications of state, is to construct an accurate mental model of the system for the user which will allow them to predict the mode accurately. This is demonstrated, for example, by some stop signs which show small diagrams describing which of the directions have a stop sign and which don't.

In the book The Humane Interface, Jef Raskin championed what he termed "quasimodes", which are modes that are kept in place only through some constant action on the part of the user; such modes are also called "spring-loaded modes".^[5] Modifier keys on the keyboard, such as the Shift key, the Alt key and the Control key, are all examples of a quasimodal interface. The benefit of this technique is that the user doesn't have to remember the current state of the application when invoking a command: the same action will always produce the same perceived result. ^[6]

See also

• Automation surprise
• Modal window
• Human computer interaction
• Interaction design
• GUI

Notes

References

• Buxton, W. A. (1995). "Chunking and phrasing and the design of human-computer dialogues" in Human-Computer interaction: Toward the Year 2000, R. M. Baecker, J. Grudin, W. A. Buxton, and S. Greenberg, Eds. Morgan Kaufmann Publishers, San Francisco, CA, 494-499.

External links

• Modelessness in UsabilityFirst glossary
• Modelessness in Apple's HIG guidelines
• Definition of mode error at Usability First
• An Example of a mode error in Excel
• John Rushby. Using Model Checking to Help Discover Mode Confusions and Other Automation Surprises. A paper discussing an automatic method for locating mode errors.
• Jakob Nielsen on Spring-loaded modes