Modes Are Still Harmful
May 5, 2026
In 1979, Jef Raskin wrote that modes were one of the fundamental design failures of computer interfaces. A mode, in his definition, is any state in which the same user action produces a different result than it would in another state. Caps Lock is a mode. A dialog box that blocks the rest of the interface is a mode. The difference between “insert” and “overtype” in a word processor is a mode.
Raskin’s argument was that modes cause a specific, predictable, unavoidable type of error: the user performs an action based on a reasonable assumption about the system’s state, and the system does something different than the user intended. The user is not at fault. They did what they meant to do. The interface failed them by allowing them to hold a false belief about what state it was in.
Forty-five years later, modes are everywhere. They have proliferated. They have found new forms. In some respects, the most advanced software of 2024 has more modes than the software of 1984.
The Classic Mode Errors
Raskin’s canonical example was Caps Lock — a key that toggles between two states, producing different results from every subsequent keystroke, with no continuous physical indication of which state you are in. The Caps Lock LED is the system’s attempt to patch this design failure by making the mode visible, but it is an inadequate patch: users look at their documents, not at the keyboard indicator light.
The Caps Lock error is so common it has become a cultural reference. You TYPE LIKE THIS without noticing. The solution — replace the toggle with a quasimode (hold shift while typing) — was obvious to Raskin in 1979. Caps Lock remains on virtually every keyboard sold today, in the same position, with the same behavior.
This is not because Caps Lock is good design. It is because it was on the keyboard in 1979, users habituated to its location, and changing it would disrupt those habits. The mode error calcifies into a permanent fixture because fixing it would create a different kind of disruption.
Modes in Modern Software
The forms modes take have evolved, but the underlying pattern has not.
Chat and collaboration tools have invented a productive new class of mode errors. Slack, Teams, and similar applications let you compose messages while reading a channel — but the compose box and the reading pane are in different modes. Users frequently type responses in the search bar, type in the wrong channel, or send messages before they intended because the interface allows them to be in an ambiguous state about where their keystrokes are going.
Mobile keyboards have introduced modes that would have horrified Raskin. The shift behavior on iOS and Android — tap once for a capital, tap twice to lock caps, tap again to release — is genuinely difficult to understand for new users, because the visual feedback between the three states is subtle and inconsistent. The same key, three behaviors, modes stacked on quasimodes.
Video conferencing has made mute-state errors into a professional hazard. “You’re on mute” became a phrase of the pandemic era because mute is a mode — a state in which your microphone behavior is different from the other state — and users lose track of which state they are in, especially after context switches (someone at the door, a phone call, a distraction). The consequences of a mute mode error range from minor embarrassment to significant professional awkwardness.
Code editors have modes baked into their core. The most popular editor among developers for decades — vi, now Vim — has a fundamental design built around two modes: insert mode, where keystrokes add text, and normal mode, where keystrokes execute commands. The learning curve for Vim is largely the learning curve for tracking mode state reliably. Vim partisans argue that the modes enable efficiency once mastered. Raskin would have agreed about the efficiency and disagreed about the necessity of modes to achieve it.
The New Frontier: AI Interfaces
The most interesting current manifestation of the mode problem is in AI chat interfaces — the category of software that has grown most rapidly since Raskin’s death.
Large language model interfaces like ChatGPT, Claude, and their competitors are, in a specific sense, deeply modal. The same text input produces radically different results depending on what has come before it in the conversation. The context window — the accumulated conversation history that the model uses to generate responses — creates a state that users cannot directly observe, partially understand, and cannot reliably predict.
This is not quite a mode in Raskin’s original sense — the input mechanism itself doesn’t change behavior, the underlying model does. But the effect is similar: users hold beliefs about the system’s state that turn out to be false. A question that would get one answer at the start of a conversation gets a different answer at the end, because the model’s “state” — its accumulated context — has changed.
The problem is compounded by the opacity of that state. With Caps Lock, at least you can see the LED. With an AI conversation context, you cannot directly observe what information the model is using to generate its response, how it has weighted earlier parts of the conversation, or what implicit assumptions have been baked in by previous exchanges.
Raskin would have identified this as a mode problem and demanded better state visibility. He would have been right.
The Quasimode Solution
Raskin’s proposed solution to modes was not to avoid them entirely in every conceivable situation — he acknowledged that some state was sometimes necessary. His solution was quasimodes: states that require continuous user action to maintain, and therefore cannot be forgotten.
The shift key is the canonical quasimode. You hold shift while typing to get capitals. You cannot forget you are holding shift, because forgetting means releasing the key, which exits the quasimode. The physical demand is the state indicator.
The quasimode principle generalizes. A “hold to talk” button on a video call is a quasimode — you cannot accidentally be in “talking” mode, because talking requires holding the button. A “hold to scroll fast” gesture is a quasimode. The physical continuity of the action prevents the state from persisting unnoticed.
Many modern interfaces have partially adopted quasimode thinking without necessarily being aware of its theoretical basis. Push-to-talk controls. Long-press behaviors that activate only while held. Swipe gestures that require continuous motion. These are quasimodes in Raskin’s sense, and they are better than the modal alternatives for precisely the reasons he identified.
Why It Matters
Mode errors seem trivial. You typed in caps when you meant lowercase. You sent a Slack message to the wrong channel. You spoke for thirty seconds on mute. Each incident is small.
The aggregate is not. Mode errors are among the most common class of computer errors that users make. They are also among the most demoralizing, because they feel like the user’s fault — the user did something stupid — when they are the interface’s fault. The interface let the user believe something false about its state. The user acted on that false belief. The interface executed faithfully.
Raskin’s argument was that every mode error is a design failure. Not a user failure. A design failure. The interface could have been designed to make that error impossible, and it was not.
Forty-five years after he made this argument, mode errors remain common, mode design remains poor, and the industry continues to treat mode errors as user error rather than design error. The argument is still worth making.
Related: