Mode (user interface)

This article is about a transient state in user interfaces. For modes in videogames, see Game mode. For other uses, see Mode (disambiguation).

Not to be confused with Multimodal interaction or Modality (human-computer interaction).

In user interface design, a mode is a state of a system in which user input is interpreted according to a particular set of rules.

Larry Tesler defines mode as "a state of the user interface that lasts for a period of time, is not associated with any particular object, and has no role other than to place an interpretation on operator input." In his book The Humane Interface, Jef Raskin defines modality as:

"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).

Accordingly, an interface is not modal as long as the user is fully aware of its current state. Raskin refers to this as locus of attention (from the Latin word locus, meaning "place" or "location"), also called heedstead in English. Typically, a user is aware of a system state if the state change was purposefully initiated by the user, or if the system gives some strong signals to notify the user of the state change in the place where interaction occurs. If the user's locus of attention changes to a different area, the state of the interface may then represent a mode since the user is no longer aware of it.

Modal

Examples of modal interfaces:

Keyboard caps lock

When enabled, each letter key pressed is interpreted as the upper case version of that letter. When not enabled, letter key presses are interpreted as lower case.

Keyboard insert/overwrite

Keyboard input is usually affected by either insert mode or overwrite mode; toggled via the insert key.

Bravo

The first WYSIWYG modal editor made for Xerox Alto computers at Xerox PARC by Butler Lampson and Charles Simonyi.

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. Derivatives, such as Vim and Neovim.

Emacs

Has the concept of "prefix keys", which trigger a modal state by pressing the control key plus a letter key. Emacs then waits for additional keypresses that complete a keybinding. This differs from vi in that the mode always ends as soon as the command is called (when the sequence of key presses that activates it is completed). Emacs also has multiple "major and minor" modes that change the available commands, and may be automatically invoked based on file type to more easily edit files of that type. Emacs modes are not restricted to editing text files; modes exist for file browsing, web browsing, IRC and email and their interaction patterns are equivalent to application software within the Emacs environment. Modes are written in Emacs Lisp, and all modes may not be included with all versions.

Cisco IOS

certain commands are executed in a "command mode".

Palette tools

Tools chosen from a palette in photo-editing and drawing applications are examples of a modal interface. Some advanced image editors have a feature where the same tools can be accessed nonmodally by a keypress, and remain active as long as the key is held down. Releasing the key returns the interface to the modal tool activated by the palette.

In video games

Video games can use game modes as a mechanism to enhance gameplay.

Modal window

Blocks all workflow in the top-level program until the modal window is closed.

Modeless

A modeless interface does not have states in which different rulesets apply. A modeless interface avoids mode errors – when a user provides input that is interpreted differently than they expect since the mode (and associated ruleset) is not what they expect.

Larry Tesler at PARC devised insights for a modeless word processor from the feedback gathered from a user test with newly-hired Sylvia Adams, where she was asked to ad lib some gestures to correct proofreading marks on the digital text. This test convinced Tesler's manager Bill English of the problems with their previous modal interface.

Mode error

Modes are problematic because they can result in an error when the user not aware of what mode the interface is in, performs an action that is appropriate in a different mode, and gets an undesired response. A mode error can be startling, disorienting and annoying as the user copes with the violation of their expectations.

Problems occur if a change in the system state happens unnoticed (initiated accidently, by the system, or by another person), or if after some time the user forgets the current mode. Another common problem is a sudden change of state that interrupts a user's activity, such as focus stealing. In such a situation it the may perform operations with the old state in mind, while the brain has not yet fully processed the signals indicating the state change.

Common examples

Keyboard lock keys

Such as caps lock, num lock, scroll lock, and the insert key.

Dead keys for diacritics

Create a short-term mode, at least if they do not provide visual feedback that the next typed character will be modified.

Multiple keyboard layouts

Users whose language is not based on the Latin alphabet commonly have to interact using two different keyboard layouts: a local one and QWERTY. This gives rise to mode errors linked to the current keyboard layout: quite often, the synchronization of "current layout" mode between the human and the interface is lost, and text is typed in a layout which is not the intended one, producing meaningless text and confusion. Keyboard keys in user interface elements like "(y/n)" can have opposite effect if a program is translated.

Modal dialog while typing

The sudden appearance of a modal error dialog while typing, which is a form of focus stealing. The user expects the typed text to be inserted into a text field, but the unexpected dialog may discard all the input, or may interpret some keystrokes (like "Y" for "yes" and "N" for "no") in a way that the user did not intend, often triggering a destructive action that cannot be reverted. Programmers can mitigate this by implementing a short delay between the modal dialog displaying and it beginning to accept keyboard input.

vi text editor

Is challenging for many beginners because it uses modes.

Control vs. messaging

In multiple video games, the keyboard is used both for controlling the game and typing messages. Users may forget they are in "typing mode" as they attempt to react to something sudden in the game and find the controls unresponsive (and instead their text bar full of the command keys pressed).

In transportation accidents

Air France Flight 447 crash

Mode confusion was part of the events that led to the loss of Air France Flight 447 in 2009, and the loss of life of 228 people. The pilots reacted to a loss of altitude by pulling on the stick, which would have been an appropriate reaction with the autopilot fully enabled, which would then have put the aircraft in a climbing configuration. However, the airplane's systems had entered a mode of lesser automation ("direct law" in Airbus terms) due to a blocked airspeed sensor, allowing the pilots to put the plane in a nose-high stall configuration, from which they did not recover.

Asiana Airlines Flight 214 crash

According to the NTSB, one of the factors contributing to the 2013 Asiana Airlines Flight 214 crash was "the complexities of the autothrottle and autopilot flight director systems … which increased the likelihood of mode error".

Red7 Alliance collision

On January 17, 2015, the offshore supply vessel "Red7 Alliance" collided with a lock gate of the Kiel Canal in Germany, damaging it severely. An investigation concluded that the levers controlling the ship's Azimuth thrusters were not used in a way appropriate to the mode they were set to, resulting in the ship accelerating instead of coming to a stop in the lock.

USS John S. McCain collision

On August 21, 2017, the US Navy destroyer USS John S. McCain collided with a commercial tanker in the Strait of Malacca, resulting in the loss of life of ten crew members. An investigation conducted by the US military concluded that immediately prior to the collision, helm and propulsion controls had been redistributed between bridge stations, and the bridge crew was not fully aware of that redistribution.

VOS Stone collision

On April 10, 2018, the 5000 ton supply vessel VOS Stone unberthed from a wind platform under construction in the Baltic Sea. The vessel's master decided to put the steering in an alternative mode to perform a test of the system. Insufficient communication with the officer of the watch led to a temporary loss of control, collision with the platform, injury to three crew members, and significant damage.

F-35 destruction

On April 19, 2020, an F-35A fighter jet was destroyed in a landing mishap at Eglin Air Force Base. Investigations concluded that the aircraft was misconfigured with the wrong mode of autothrottle, resulting in the aircraft becoming uncontrollable upon touchdown.

Manawanui grounded

On October 5, 2024, the New Zealand Navy hydrographic vessel Manawanui ran aground on a reef off Siumu, Upolu, Samoa, and sank the following day. According to an official inquiry, the bridge crew failed to recognize that the ship's autopilot was enabled.

Assessment

Modes are intended to grab the user's full attention and to cause them to acknowledge the content present in them, in particular when critical confirmation from the user is required. This latter use is criticised as ineffective for its intended use (protection against errors in destructive actions) due to habituation. Actually making the action reversible (providing an "undo" option) is recommended instead. Though modes can be successful in particular usages to restrict dangerous or undesired operations, especially when the mode is actively maintained by a user as a quasimode.

Modes are sometimes used to represent information pertinent to the task that do not fit well into the main visual flow. Modes can also work as well-understood conventions, such as painting tools.

Modal proponents may argue that many common activities are modal and users adapt to them. An example of modal interaction is that of driving motor vehicles. A driver may be surprised when pressing the acceleration pedal does not accelerate the vehicle in the forward direction, most likely because the vehicle has been placed in an operating mode like park, neutral, or reverse. Modal interfaces require training and experience to avoid mode errors like these.

Interface expert 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'." Raskin dedicated his book The Humane Interface to describe the principles of a modeless interface for computers. Those principles were implemented in the Canon Cat and Archy systems.

Some interface designers have recently taken steps to make modal windows more obvious and user friendly by darkening the background behind the window or allowing any mouse click outside of the modal window to force the window to close – a design called a Lightbox – thus alleviating the risk of modal errors. Jakob Nielsen states as an advantage of modal dialogs that it improves user awareness. "When something does need fixing, it's better to make sure that the user knows about it." For this goal, the Lightbox design provides strong visual contrast of the dialog over the rest of the visuals. However, while such a method may reduce the risk of inadvertent wrong interactions, it does not solve the problem that the modal window blocks use of the application's normal features and so prevents the user from taking any action to fix the difficulty, or even from scrolling the screen to bring into view information which they need to correctly choose from the options the modal window presents, and it does nothing to alleviate the user's frustration at having blundered into a dead end from which they cannot escape without some more or less destructive consequence.

Larry Tesler, of Xerox PARC and Apple Computer, disliked modes sufficiently to get a personalized license plate for his car that read: "NO MODES". He used this plate on various cars from the early 1980s until his death in 2020. Along with others, he also used the phrase "Don't Mode Me In" for years as a rallying cry to eliminate or reduce modes.

Bruce Wyman, the designer of a multi-touch table for a Denver Art Museum art exhibition argues that interfaces for several simultaneous users must be modeless, in order to avoid bringing any single user into focus.

Design recommendations

Avoid when possible

Small signs make explicit the mappings from signal to roads.

Alternatives to modes such as the undo command and the recycle bin are recommended when possible. HCI researcher Donald Norman argues that the best way to avoid mode errors, in addition to clear indications of state, is helping the users to construct an accurate mental model of the system which will allow them to predict the mode accurately.

This is demonstrated, for example, by some stop signs at road intersections. A driver may be conditioned by a four-way stop sign near his or her home to assume that similar intersections will also be four way stops. If it happens to be only two way, the driver could proceed through if he or she sees no other cars. Especially if there is an obstructed view, a car could come through and hit the first car broadside. An improved design alleviates the problem by including a small diagram showing which of the directions have a stop sign and which do not, thus improving the situational awareness of drivers.

Proper placement

See also: Design recommendations for modal windows

Modal controls are best placed where the focus is in the task flow. For example, a modal window can be placed next to the graphical control element that triggers its activation. Modal controls can be disruptive, so efforts should be made to reduce their capacity to block user work. After completing the task for which the mode was activated, or after a cancel action such as the Escape key, returning to the previous state when a mode is dismissed will reduce the negative impact.

Quasimodes

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. The term quasimode is a composite of the Latin prefix quasi- (which means almost, to some degree) and the English word "mode".

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 application enters into that mode as long as the user is performing a conscious action, like pressing a key and keeping it pressed while invoking a command. If the sustaining action is stopped without executing a command, the application returns to a neutral status.

The purported benefit of this technique is that the user does not have to remember the current state of the application when invoking a command: the same action will always produce the same perceived result. An interface that uses quasimodes only and has no full modes is still modeless according to Raskin's definition.

The StickyKeys feature turns a quasimode into a mode by serializing keystrokes of modifier keys with normal keys, so that they do not have to be pressed simultaneously. In this case the increased possibility of a mode error is largely compensated for by the improved accessibility for users with physical disabilities.

See also

• Application posture
• Automation surprise
• Error message
• GUI
• Human computer interaction
• Interaction design
• Modal window
• Modalities and modes
• State (computer science)
• Text mode

References

• Buxton, William A. S. (1995). "Chunking and phrasing and the design of human-computer dialogues". In Baecker, Ronald M.; Grudin, Jonathan; Buxton, William A. S.; Greenberg, Saul (eds.). Readings in human-computer interaction : toward the year 2000 (2 ed.). San Francisco, Calif.: Morgan Kaufmann. pp. 494–499. ISBN 978-1-55860-246-5. acmid 212970.

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