A long stall needs a stage explanation

What it is

The bar is still there, the number is not rising: that is a stall. A stall is not a failure, but it looks like one. Predictability requires that once the stall outlives the short stretch where inertia still says “it is moving”, a current stage fills the silence: verifying, queued on the server, writing to disk. The stage says “the work has changed shape, so the bar is allowed to sit still”. It does not invent a percent that keeps climbing.

Why it happens

Determinate progress binds “still working” to displacement. When displacement stops, the bind breaks, and only two readings remain: hung, or entered a kind of work the UI cannot show. A brief pause can ride inertia — jitter, a buffer filling. Past inertia, “broken” takes the explanation. Stage copy takes it back: it offers evidence that does not depend on displacement, proof the process is still in a state machine, just in a state with no countable numerator to add.

The stage also has to be a real stage, not comfort. Refreshing the same “processing” line forever still has zero information, same as writing nothing. A useful stage changes: upload → server scan → preview. Each change lets people recalibrate why the bar is still. What is recalibrated is the model, not the speed — speed may remain zero; the model must not be empty.

Where it stops holding

A pause shorter than the window in which thought still runs continuous does not need a stage; flashing subtitles are louder than silence. When there are few steps and each already has a visible scene change (wizard pages), the page is the stage; do not stack a tautology next to the bar. If the stage is a guess (the hang is actually unknown), a fake stage is worse than none, because the next second will falsify it. Prefer “still working; this step’s duration is unstable” over a carousel of invented operations. If the main thread freezes so the bar and the copy stop together, a stage cannot save it — put status on a layer that can still refresh. After reversals are banned, stalls become more common (the bar freezes when the total grows), so this leaf is paired with monotonic progress: if the bar may not jump back, it must be able to speak.

Applying it

• Put a stall timer on progress. After it fires with no numerator growth, show the current stage rather than leaving the bar to fake life.
• Use real, switchable operation names, and update them when the operation changes. Do not use an immortal “please wait”.
• Keep cancel or switch-away available during the stall. A stage is not a reason to pin people to the screen.
• How to check: inject a ten-second-plus server queue in which the percent does not move. The UI should name that queue. A frozen bar alone means predictability has already broken.

Related

• Same group: I2.02.1 Progress must be monotonic and must not run backwards · I2.02.3 Inaccurate remaining-time estimates damage trust
• Nearby: I2.01 Choosing skeleton versus spinner · I1.03 Attention-holding ceiling · I3.07 Background tasks
• Search terms: progress stall · stage explanation · determinate hang