Do not show an indicator for a very short load
Aliases: spinner delay · show threshold · flash of spinner
What it is
A loading indicator—a spinner, pulsing dots, or the word “Loading”—tells people the system is still working. Not showing it for a very short load means that if the request finishes inside the window where the action still feels like it is happening, the indicator should never appear. A spinner that flashes once is not honesty; it costumes a finished act as a wait and makes the interface manufacture a pause. This leaf is the show threshold: when display may begin. How long it must then stay, and whether it may cover the page, are the next leaves.
Why it happens
After an action just issued, there is a stretch that is still coded as “this act is occurring.” An unchanged screen in that stretch remains part of the same act; a spinner recodes the same stretch as “I am waiting on the system.” Once that recoding happens, even an immediately vanishing spinner leaves a pointless state change—a flicker. Flicker captures attention and implies the system is busier than it is. The threshold is not taste: direct manipulation and key feedback can be near zero, while a network fetch often should pass this immediate window before being admitted as a wait. An indicator’s job is to mark a wait already outside the immediate window. Marking a wait still inside it breaks the sense of cause.
Studying it
Insert controlled delay after the same action and compare “spin as soon as the request starts” with “spin only after a threshold.”
Independent variables: delay length, action type (local filter / networked save), whether the indicator interrupts content currently being read. Dependent variables: reports of “it hiccuped,” repeat-click rate, subjective duration, judged instability.
The critical contrast is a truly short delay with a spinner that flashes: objective time identical, the flash group remembers the task as slower and less reliable. Do not score “did you see the spinner” as success; seeing it is the failure in this condition.
Where it stops holding
An action with no other feedback at all (the button’s look never changes) may still need a different immediate acknowledgement even when fast—that is button state, not an indicator. When people already expect a slow process (export, payment), the threshold can be lower because the wait is already in the forecast. On a weak network, “usually fast” becomes “often slow,” and a fixed threshold lets the indicator arrive late, so people repeat-click inside the threshold; prevent re-entry rather than dropping the threshold to zero. Starting a spinner for a request of a few tens of milliseconds is also a performance cost for nothing.
Applying it
- Give the indicator a show delay; requests that finish sooner stay quiet, with only the control’s immediate state (pressed, disabled).
- Split thresholds by action type: local filtering can wait longer before admitting a wait; a cross-region request can admit sooner.
- Do not default to “spin on every request”; default to “prove this one is actually waiting.”
- Verify on a fast network by tapping common actions and watching for a one-frame spinner. If it appears, raise the show delay until those fast requests stay quiet.