Mode (User Interface) (Wikipedia)
Wikipedia’s article on interface modes — states in which the same input produces different results.
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Key points
- Larry Tesler’s definition: “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.” Jef Raskin’s definition adds a second condition: a gesture is modal specifically when the current interface state isn’t the user’s locus of attention and the same gesture produces different results depending on that state.
- Modal examples: Caps Lock and insert/overwrite typing modes; vi and Emacs’s editing modes; palette/tool selection in image editors; modal windows and dialogs.
- Quasimodes (spring-loaded modes): a mode held only by continuous user input — modifier keys (Shift, Alt, Control) are the standard example — so the user never has to remember or track state; releasing the input exits the mode automatically.
- Mode errors: performing an action correct for the mode the user believes is active, while the system is actually in a different one. Most likely when a mode change goes unnoticed, is forgotten after time passes, or is interrupted by something stealing focus.
- Real-world consequences: Air France Flight 447 (2009) — a blocked airspeed sensor dropped the autopilot into a reduced-automation “direct law” mode; pilots, believing full automation was still active, pulled the stick to climb, causing a nose-high stall they never recovered from. Asiana Airlines Flight 214 (2013) — the NTSB cited the complexity of the autothrottle/autopilot flight-director system’s mode logic as increasing the likelihood of mode error. USS John S. McCain (2017) — helm and propulsion control had been redistributed between bridge stations without the crew’s awareness, producing confusion about which station currently controlled what.
- The case against modes: Larry Tesler campaigned against modes throughout his career at Xerox PARC and Apple, reportedly keeping a “NO MODES” license plate for decades. Jef Raskin’s The Humane Interface argues modes are “a significant source of errors, confusion, unnecessary restrictions, and complexity,” and describes the modeless Canon Cat and Archy systems built on that principle. The vi editor’s modal design is a long-running point of debate specifically because of its learning-curve cost.
- Assessment: modes have legitimate intended uses — grabbing attention for a critical confirmation, holding task-specific tools (a painting palette) that don’t fit the main flow, or working as an already-understood convention. Their disadvantages: habituation makes them ineffective at actually preventing errors, they require training, and a mode that blocks normal functionality frustrates users pursuing a different task. The article’s recommended alternative to a protective mode (one that exists to block a mistake) is a reversible action — undo — instead.
- Design recommendations: avoid modes where possible; where a mode is unavoidable, make the current state clearly visible (a changed cursor, a distinct visual treatment, a sound) rather than requiring the user to remember it; prefer a quasimode over a persistent mode when feasible; keep a modal dialog’s controls positioned near what triggered it, and let Escape or an outside click return to the prior state.