When structure cannot be predicted, use an indeterminate indicator

What it is

An indeterminate indicator — spinner, pulsing dots, a bar that only travels — asserts that work has not finished. It does not assert forthcoming geometry. When structure still depends on this payload, this query, this generated result, that is the honest wait language. Drawing a skeleton anyway is guessing at layout; a lucky guess is still a guess, and a wrong one tears up spatial expectations on arrival.

The selection flips here. Unknown structure is not “no wait feedback”. It is a ban on filling a structureless interval with the language of structure.

Why it happens

A skeleton’s power is rehearsal, and rehearsal needs a map that predates the data. A search page changes shape for zero hits, ten hits, or a chip row; a conversation jumps among bubbles, cards and tool calls; a generative canvas grows an unknown number of blocks from blank. Those shapes live in the response, not in the route. Any grey block is then an unbacked cheque: vision partitions the screen against it, the payload arrives, the partition is void, and the rehearsal becomes a model that has to be withdrawn.

An indeterminate indicator refuses to partition. It anchors the wait on a marker that occupies no content slot, usually near the control or in a neutral spot of the region. The model people get is “still working”, not “three rows incoming”. The model is thinner, so it does not go bankrupt on arrival. The cost is equally clear: orientation waits for real content, and less spatial preparation can happen during the same clock time. When structure is unknown, that cost is cheaper than a map that will be torn up.

Where it stops holding

“Not known yet” is not “never known”. The next step of a wizard, or the list after a filter, often reveals its template shortly after the request leaves; the treatment can upgrade from spinner to skeleton on that beat rather than ride the spinner to the end. When a total is actually known (file size, export rows), an indeterminate mark does not say how much remains — step up to determinate progress instead of spinning because “the layout is not drawn yet”. A local refresh of a known card has predictable structure for that card; covering the whole page with a spinner is the wrong scope. On assistive channels, a spinner with no “loading” equivalent does not become silence just because structure is unknown.

Applying it

• Branch on whether structure is written in the route or template. If it is, skeleton. If it lives in the response, wait with an indeterminate indicator; do not fake every page with a generic three-row grey stack.
• Allow an upgrade mid-wait once the shape is known: list versus canvas can switch to a matching skeleton or a determinate bar.
• Place the indicator in the region this wait belongs to. Unknown structure is not a reason to go full-screen modal.
• How to check: on search, generation and permission-forked pages, capture a frame before the payload returns. If that frame already draws a specific row count or module shape, and live results often look different, the selection is wrong.

Related

• Same group: I2.01.1 Use a skeleton when the forthcoming structure is predictable · I2.01.3 A skeleton that does not match real structure produces a jump · I2.01.4 Skeletons reduce subjective wait estimates more than spinners · I2.01.5 An indicator on a very short load creates needless flicker · I2.01.6 A spinner carries no progress and, used for long, is read as frozen · I2.01.7 Skeleton motion needs one shared cadence; mixed breathing looks cheap
• Nearby: E6.08 Loading indicators · E6.09 Determinate and indeterminate progress · I1.02 Continuity-of-thought threshold
• Search terms: indeterminate indicator · unknown structure · spinner versus skeleton