The Progress Bar#
Week 5 — interfaces
A hypothetical, to start#
A file is copying. A bar fills from left to right.
A percentage climbs: 40, 50, 60…
(Illustrative — not a specific observation.)
Where we’ve been#
Three mechanisms have built our vocabulary for reading a wait:
- Attention — what we attend to
- Expectation — what we expected
- Information — what information arrived
Now we turn that vocabulary outward#
Onto the system doing the waiting with us.
Analyse block: how waits get built.
Week 5 (interfaces) + Week 6 (environment) — the first matched pair.
Week 4 established a distinction#
Whether explicit information was available during the wait —
arriving only after it had already begun, separate from Week 3’s expectation, set before a wait starts.
Week 5 asks a different question#
Given that a system represents the wait’s state — what does its behaviour communicate about the process as it unfolds?
Steady. Paused. Accelerating. Indeterminate.
A caution before the evidence#
“Representation,” “shape,” “trajectory,” “implied completion” — this course’s own vocabulary.
Not the research literature’s. The measured part is narrower: perceived speed, preference, under a fixed duration.
Harrison, Amento, Kuznetsov & Bell (2007)#
“Rethinking the Progress Bar” — UIST’07#
Nine synthetic progress-bar behaviours. 22 participants. Paired comparisons.
The task#
Two bars, side by side. Which one seemed to finish faster?
Every bar — every trial — ran for exactly 5.5 seconds, fixed.
What they found#
- A pause near the end → perceived as slower
- Acceleration near the end → perceived as faster, preferred
- Whichever bar was seen first → mildly preferred, regardless of behaviour
What this is not#
Not a study of real, minutes-long waits.
Not a measure of what participants expected.
Not this course’s free-form “Judged duration” field.
Not “progress bars make waits feel shorter,” universally.
Myers (1985) — a formal experiment#
Percent-done indicators:
- give information about progress and completion
- help estimate how much is done, or roughly when a task will finish
- a formal experiment found a significant preference for systems with an indicator over systems without one
Two papers, two different questions#
| Source | Question | Maps onto |
|---|---|---|
| Myers | What changes when a progress indicator is present? | Connects back to Week 4’s disclosure question |
| Harrison et al. | What changes when the progress behaviour itself changes? | Week 5’s new question |
“Shape / trajectory / representation” is our analytical vocabulary, layered on top of these two findings — not a term either paper used.
What none of this licenses#
- That an accelerating bar is always the better design
- That a fast finish always reassures — a payment, a medical result?
- That any of this generalises past a short, fixed, controlled comparison
This week’s log#
Find one ordinary digital wait with a progress or status representation — a bar, a countdown, or an indeterminate spinner.
Log it — Week 1’s fields, plus Interface representation, a Week 5 extension of the same instrument.
Write the two-part comparison: what it communicated partway through → what actually happened.
Observational only — no manipulation, no induced stalls.
Next week#
Same question. No screen.
Week 6 asks what a physical room communicates about how a wait will go.