Patterns

PTN·03·001

The Modal

Earns its place — narrowly documented

A modal is an interruption with a door policy: it seizes focus, dims the world behind it, and refuses to let anything continue until its one question is resolved. That seizure is the entire design — and the entire risk. Used precisely, it is the interface saying this cannot wait. Used habitually, it is the interface saying we don't trust you to notice things, forty times a day.

AnatomyScrim (the dimmed world) · container · title stating the decision · the content of the decision · a primary action, a safe exit, and — non-negotiably — an escape hatch (Esc, scrim-click, or an explicit close) that maps to the safe exit.

Use when

A decision must be resolved before anything else can continue
The action is destructive and the cost of a mis-click exceeds the cost of interruption
The task is short, self-contained, and loses meaning outside its context

Avoid when

The content could simply live on the page behind it
The task involves reference to the page you just hid
It fires on arrival — a modal nobody asked for is an ad
An undo would make the confirmation unnecessary

States & accessFocus moves into the dialog and is trapped there; Esc closes; focus returns to the trigger on dismissal; the page behind is inert to assistive tech (role="dialog", aria-modal). A modal that loses the keyboard has failed at the primitive level, whatever it looks like.

FIG 03·001 — the door policy, drawn.

HistoryModal dialogs predate the GUI — the concept ships with early windowing systems (Smalltalk, Lisa/Macintosh era); the term "modal" names the mode error it risks.

SpecimensOS file-delete confirmations (earned) · newsletter pop-ups on arrival (unearned) · payment 3-D Secure (imported, unloved).

Principle at stakeFeedback & mode — see the Stairwell; when the seizure isn't justified, see the Basement.

SourcesPlatform primary sources (Apple HIG, Material dialogs guidance); Nielsen on interruption cost. Specimens own-captured, dated.

Why documented: The ARIA Authoring Practices specify the dialog’s focus trap, Escape, and focus return. The access requirements are not opinion.

PTN·03·002

Undo vs Confirm

The mercy pattern traditional

Two ways to protect a person from their own click. Confirm interrupts before the act: are you sure? — asked so often that the honest answer becomes a reflex, and the reflex defeats the protection. Undo permits the act and holds the door open after it: done — undo? One pattern taxes every action to protect the rare mistake; the other taxes nothing and rescues the mistake itself.

The judgment of this floor: undo beats confirm wherever undo is possible. Gmail's send-undo did more for email regret than twenty years of confirmation dialogs. Confirm survives for the genuinely irreversible — deletion that truly deletes, payments that truly move — and for nothing else. A confirm guarding a reversible action is an interruption cosplaying as safety.

Undo — use when

The action can be held, delayed, or reversed cheaply (send, archive, move, apply)
The action is frequent — frequency is exactly where confirm fatigue breeds
The cost of a five-second hold is invisible to the user

Confirm — reserve for when

Reversal is genuinely impossible (permanent deletion, sent money, published-to-world)
The consequence lands on someone else, who can't be un-notified
Law or safety demands an explicit second assent

FIG 03·002 — where each pattern spends the user's attention.

HistoryUndo enters computing with Xerox PARC's editors (1970s); its modern rehabilitation as a *shipping* mercy is the Gmail send-undo era.

SpecimensGmail undo-send · toast-with-undo after archive · the delete-confirm that guards a trash folder (the anti-specimen: double protection of a reversible act).

Principle at stakeError tolerance & feedback — Stairwell. Confirm fatigue is a mode of basement failure.

SourcesNorman on error design; platform toast/snackbar primary docs; Nielsen on confirmation fatigue.

Why traditional: “Undo beats confirm wherever undo is possible” is this floor’s judgement and long practice, not a measured result.

PTN·03·003

Skeleton screens

Perceived performance traditional

A skeleton screen shows the shape of content before the content — grey bars where text will land, a grey disc where the avatar will be. It replaces the spinner's honest message (the machine is busy) with a structural promise (here is what's coming). The wait is identical; the experience of it is not, because attention has somewhere to go.

Use when

Layout is predictable — the skeleton can tell the truth about the shape
Loads sit in the awkward 0.3–3s band: too long to ignore, too short for progress bars
Content arrives progressively and slots can fill as they land

Avoid when

The skeleton lies — placeholder shapes that don't match the arriving layout create a double load
The wait is long: past a few seconds a skeleton becomes a locked room; show progress or say the truth
It masks a performance problem that should simply be fixed

FIG 03·003 — a promise about shape. It must be kept.

HistoryTerm coined by Luke Wroblewski (2013); popularized by Facebook's feed placeholders.

SpecimensFeed placeholders everywhere · YouTube's grey grid · the anti-specimen: skeletons that reflow on arrival.

Principle at stakeFeedback & the 1-second threshold — Stairwell.

SourcesWroblewski (2013); perceived-performance literature; platform loading-state guidance.

Why traditional: A perceived-performance practice. The claim that skeletons feel faster than spinners is contested in the literature, so it is not marked documented.

The Anti-patterns Annex

ANX·03·A01

The Carousel

Flagged on sight documented

The carousel is what a homepage does instead of making a decision. Five stakeholders, five banners, one rotating frame — the conflict resolved by hiding four of the five messages at any moment and animating the evidence. The pattern's popularity is entirely internal: it solves a meeting, not a user need.

The record is unusually one-sided: interaction concentrates overwhelmingly on the first slide, auto-rotation moves content while people are reading it (an accessibility failure on its own — WCAG's pause-stop-hide criterion exists substantially because of this pattern), and banner-blindness treats the whole region as an ad. The Institute flags it on sight; the burden of proof sits with the carousel.

Survives only as

A user-driven gallery of equivalent items (product photos), swiped by choice, never auto-rotating
A browsing shelf where sequence is the content (episode rails) — with full keyboard and pause control

Dies as

The homepage hero rotator — the canonical form
Any auto-advancing frame containing text someone might be reading
A compromise between departments

FIG 03·A01 — the audience never turns the page.

Principle brokenAttention is spent without consent; motion fights reading — Stairwell: feedback & control.

SourcesNN/g carousel research; Runyon's shouldiuseacarousel lineage; WCAG 2.2.2 pause-stop-hide.

See alsoThe Basement holds its cousins: the hover-menu and the forced tour.

Why documented: The case against is published: interaction concentrates on the first slide, and WCAG 2.2.2 Pause, Stop, Hide exists substantially because of auto-rotation.

5 Whole systems open

3 Patterns open

1 Primitives open

G Collections open

S The Stairwell open

B The Basement open

The rest of the building

Undo vs Confirm

Undo — use when

Confirm — reserve for when

Skeleton screens

Use when

Avoid when

The Carousel

Survives only as

Dies as

Held in outline