A spinner carries no progress and, used for long, is read as frozen

What it is

A spinner is periodic motion. Periodic motion proves that some loop is still painting, not that work is advancing. On a short wait that is enough: people only need to know the system is not dead. Once the wait outlives the window attention can hold, the same spinner is recoded — from “still working” to frozen. People kill the process, submit again, or declare the UI unresponsive. This leaf is the time limit of an indeterminate indicator as wait language: it has no progress channel, and cannot carry a long wait alone.

Why it happens

“Still working” and “how far the work has gone” are different questions. A spinner has phase, not accumulation: the first second and the thirtieth can look identical, the only difference being whether the person remembers how long they have been looking. With no accumulation, resource allocation — keep watching, switch away, cancel — is guesswork. Guessing is cheap on a short interval; as the interval stretches, the guess is colonised by “maybe it already stopped”, because a dead UI and a spinner whose information never changes are hard to tell apart from outside.

Periodic motion also habituates. After a while the spinner drops from signal to background texture, and the evidence of life gets weaker. A skeleton on a long wait is misread as a broken real page, a different error; a spinner is misread as “the loop is running, the job is not”. One failure is identity blur, the other is a missing progress channel. In selection, leave spinners for waits whose structure is unknown and that are not expected to be long. Once the wait is expected to cross the window, switch to language that accumulates — stage names, a determinate bar, a queryable background task — rather than drawing a larger spinner.

Where it stops holding

Game spinners and branded splash screens already sit in a “this is an interlude” model, so the freeze threshold sits higher — not infinitely high. A determinate bar stuck on one percent is also read as frozen; what is missing then is a stage note during stall, not a spinner. When local work saturates the main thread the spinner itself freezes, the “it is moving” evidence dies, and a hang judgement is almost certain — put the indicator on a layer that does not depend on that thread, or use a system wait that does not block. An assistive “loading” announced once with no follow-up is the same channel exhaustion as a long visual spinner. Uninterruptible short handshakes (a few seconds of payment confirmation) can ride a spinner, but they must actually be short and named up front.

Applying it

• Give the spinner a time budget. Actions expected to cross the attention-holding window should not be spinner-only. Upgrade to stage copy, determinate progress, or a path into a queryable task list.
• When structure is unknown but the job will be long, keep an indeterminate mark, but pair it with text naming the kind of work so information content changes at least once.
• The spinner has to move. On paths where the main thread may freeze, put the indicator on a layer that can refresh independently, so “the spinner stopped” is not the only evidence.
• How to check: stretch a request past twenty seconds with only a spinner. Ask the person waiting whether it is working or broken. If they cannot say, or have already gone to kill the app, the spinner has been read as frozen.

Related

• Same group: I2.01.1 Use a skeleton when the forthcoming structure is predictable · I2.01.2 When structure cannot be predicted, use an indeterminate indicator · 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.7 Skeleton motion needs one shared cadence; mixed breathing looks cheap
• Nearby: E6.09 Determinate and indeterminate progress · I1.03 Attention-holding ceiling · I2.02 Predictable progress
• Search terms: spinner frozen · indeterminate hang · progress channel