The OSBR Handbook
Sign in

Modeless Design

This policy defines OSBR's default posture for interaction: modelessness is the default; a mode is the exception that must justify itself. A mode is any state where the same user action produces a different result depending on where the interface currently is — the classic example being a modal dialog that seizes the screen and refuses every action but its own. Whenever a design reaches for a mode, the burden is on the design to prove the mode is warranted, and to record why. It sits under the Design Guidelines and sharpens one thread of Interaction Design down to the altitude of a single interaction. Deviations are allowed, but — as everywhere in the handbook — they must be deliberate and recorded in the project's design notes.

We do not invent our own interaction theory. We stand on named, published practice — Jef Raskin's The Humane Interface on modelessness, Larry Tesler's lifelong campaign against modes, the Nielsen Norman Group's modal-dialog guidance and the user control and freedom heuristic, Apple's Human Interface Guidelines and Google's Material dialog guidance, and the W3C WAI-ARIA Authoring Practices dialog pattern — and apply it at the altitude of a single interaction. The accessibility obligations a mode must still satisfy when it does exist live in Accessibility; this page is where interaction design decides, one interaction at a time, whether a mode should exist at all.

How to read this policy

1. Goal

The goal is an interface where the user is always in a place they chose to be, and can always leave it. A mode — most visibly a modal dialog — takes control away from the user: it decides what they may do next and blocks everything else. The default is to not do that. When the interface must impose a mode, it does so briefly, for a reason the user can see, and with the door left unlocked.

Raskin's argument is the root of this policy: modes are a principal cause of user errors, because a person acts on their intent while the system acts on its hidden state, and the two diverge (Jef Raskin, The Humane Interface, 2000). Larry Tesler spent his career on the same point — his "NOMODES" licence plate and the maxim "Don't mode me in" name the whole discipline. A modeless interface lets the user's habits transfer everywhere because the same gesture always means the same thing.

This is what "Be Kind" looks like in interaction

OSBR's values are Be Nice, Be Kind, and Be Strong. Be Nice is, when a mode is genuinely justified, making it painless — obvious exits, preserved input, a readable background — so even the necessary mode respects the person inside it. In interaction design, Be Kind is literal: never trap the user in a mode. A modal the user cannot escape, that eats their half-typed input when it closes, or that hides the context they were reading, is unkindness encoded in software. Be Strong is refusing the lazy modal that exists only because it was easier to build than an inline flow.

2. Responsibility

Whoever designs an interaction owns the decision to introduce a mode. Concretely, that person or pair MUST:

This is not a hand-off to a separate role who audits modals at the end. The person who introduces the mode is the person who justifies it, because the two are the same decision.

3. Practices

3-1. Modeless by Default; a Modal Only for Justified Cases

The NN/g guidance on modal & nonmodal dialogs is blunt: modals interrupt and demand action, so they should be reserved for the few situations that genuinely need to stop the world. Everything else — editing, creating, filtering, previewing — SHOULD happen inline, in a panel, on its own page, or in a nonmodal surface the user can ignore and return to.

A modal is justified only when the interaction is one of these:

The default carries no burden; the mode does

A modeless design needs no defence — it is the baseline. A modal is a claim that this interaction is special enough to take control away from the user. If that claim cannot be written down in a sentence tied to one of the three cases, the claim is false and the modal should not ship.

3-2. Hold State in the URL, Not in the Mode

A mode that lives only in transient in-memory state is a place with no address: the user cannot bookmark it, share it, reload into it, or navigate back out of it with the browser's own controls. Raskin's modelessness has a direct web-era corollary — the URL is the application's modeless state. NN/g's user control and freedom heuristic (heuristic 3 of the 10 Usability Heuristics) wants a clearly marked exit at all times; the browser's Back button and address bar are that exit, and they only work if state is in the URL.

The Back button is a modeless exit you get for free

When the current place is in the URL, the browser's Back button already does what §3-3 asks every modal to do — it lets the user leave. Building on the URL means you inherit a universal exit instead of reimplementing one badly.

3-3. Multiple Exits, and Never Eat the User's Input

If a mode must exist, it must be trivial to leave, and leaving must not punish the user. The WAI-ARIA Authoring Practices dialog (modal) pattern requires that Escape closes the dialog — this is a baseline accessibility expectation, not a nicety. NN/g's user control and freedom heuristic frames the rest: users need a clearly marked way out that does not force them through an unwanted flow.

Dismissal is safe by default; only destruction is guarded

The asymmetry is deliberate. Cancelling is always harmless, so it should be effortless and available every way — Escape, background click, Close. Committing something irreversible is the only thing that earns a deliberate, guarded gesture. Guard the destruction, never the retreat.

3-4. Trap Focus, but Keep the Background Readable

A modal has two audiences at once — a keyboard or screen-reader user who must not be able to tab out into dead background controls, and a sighted user who often needs the context behind the dialog to answer it. Both the WAI-ARIA APG dialog pattern and the platform dialog guidance (Apple's Human Interface Guidelines — Modality, Google's Material dialogs) speak to this: contain interaction, but do not obliterate context. The full accessibility bar these rules serve is set out in Accessibility.

Contain the focus, not the understanding

Focus trapping is a mechanism for correctness — it keeps keyboard and screen-reader users from wandering into an inert background. It is not a licence to hide that background from the eye. Trap the interaction; keep the information visible.

4. What "Modeless by Default" Requires, Per Interaction

Before an interaction that introduces a mode is called finished, it MUST satisfy all of the following. This is the checklist the practices above add up to — the bar the Quality Gate holds a mode to:

Requirement The question it answers
Justified case Does this modal fit one of the three cases — irreversible confirmation, single submission unit, physically-exclusive interaction? (§3-1)
Recorded trade-off Is the reason for the modal written in the PR or an ADR? (§3-1)
URL state Is the place addressable, shareable, and reload-survivable via the URL? (§3-2)
Multiple exits Do Escape and a background click both close it? (§3-3)
Preserved input Does closing keep the user's in-progress input rather than discarding it? (§3-3)
Focus trapped Is keyboard/AT focus contained in the modal and returned on close? (§3-4)
Readable background Is the context behind the modal still visible? (§3-4)
Announced correctly Does the dialog carry role, aria-modal, and a label? (§3-4)

An interaction that works but fails any row above is not finished — it has introduced a mode without earning it, or built a mode that traps the person inside it.

6. References

Named, published practice this policy is grounded in — each a documented source an SME can adopt directly.

Modelessness

Modal-dialog usability

Platform dialog guidance

Accessibility