When a total can be estimated, progress must be determinate
Aliases: percent-done · progress bar · known total
What it is
Determinate progress speaks in completed-over-total: twelve of thirty, forty percent, step three of ten. When the system already knows the total—file bytes, export rows, installer steps—and still offers only a sliding indeterminate bar, it is hiding information it has. The claim here is strict: if the total can be estimated, progress must be determinate. The indeterminate bar is for when the total is genuinely unknown. Animating a fake ratio is the next leaf.
Why it happens
People waiting are allocating resources: keep watching, switch away, or cancel. A ratio supplies structure for that decision, not comfort. Knowing the work is at seventy percent lets someone judge whether the remainder is worth holding the link; a bar that merely moves leaves the allocation to guesswork. Determinate progress also splits “the system is still working” from “how far the work has gone.” A spinner can answer the first; the second needs a total. Estimable does not mean exact to the byte: step counts, records processed, chunks transferred are totals. Having a total and refusing to show it is usually laziness or fear that the ratio will stall. A stall is honest. Hiding it so people cannot decide is the larger failure.
Studying it
Give one measurable task three treatments: a determinate bar, an indeterminate bar, and a spinner only. Allow cancel or switching to another task.
Independent variables: whether a ratio is shown, whether remaining time is attached, whether the task truly has a known total. Dependent variables: whether cancels happen at a reasonable remainder, rate of switching away and returning, subjective remainder, reports of “no idea how long.”
If the lab forbids cancel, the decision value of determinate progress cannot be measured—only “felt fast.” Build cancel and switching into the task so the ratio has something to explain. With very few steps (two in all), a determinate bar has too little resolution and feels deceptive; that is a granularity problem, not a reason to fall back to indeterminate.
Where it stops holding
When the total grows mid-flight (more files inside an archive, the server appending a batch), a determinate bar will jump backward or suddenly slow. Backward jumps hurt, but switching to indeterminate throws away a ratio that later stabilizes; better to revise the denominator, keep completed work, and if needed add “more items found.” When the total is a casual server ceiling that is often wrong, a determinate bar systematically misleads; degrade, and upgrade again when real progress can be measured. Operations so short that an indicator should not appear at all do not need a bar that flashes to a hundred percent in the name of “must be determinate.”
Applying it
- Default to a determinate bar for anything countable: transfers, queues, steps. Treat indeterminate as the “total unknown” branch, not the default skin.
- Write units beside the ratio: 12 / 30 images, 40 MB uploaded, not a bare percent.
- When the total is revised, update the denominator rather than leaping the bar backward; if a backward jump cannot be avoided, change the copy with it.
- Verify by asking someone in the wait how much is left. If they cannot say, and logs already have a total, determinate was required and unused.