What 99% promises#
SLOP2805 · Week 1
Still Loading: The Design of Progress Bars
It sat at 99% for eleven seconds#
Then it said the upload failed.
Which of those two things was the lie?
By the end of Thursday#
This is week 1, so there is nothing to build on. There is one move to learn, and you will use it for eleven more weeks.
By 17:00 you can:
- list every claim an interface makes, including the ones made by motion and by silence
- name an event that could support each, or say that none could
- tell a claim that is false from one you simply cannot check from outside
A claim is anything the interface asserts#
- a number — “99%”, “about 4 minutes remaining”
- a word — “Finalising”, “Almost done”, “Complete”
- a motion — a bar that accelerates is claiming something about rate
- an absence — a screen showing nothing claims nothing needs saying
If a reader can take something from it, it is a claim.
A source event is something the process reports#
Not something it does. Something it emits, at a time you could write down.
| the process does | the process reports |
|---|---|
| writes bytes to a socket | progress: 4.2 MB of 11 MB |
| waits on a server lock | (nothing) |
| finishes durably | committed |
The middle row is where progress bars are invented.
Three verdicts, this week only#
sourced— an event exists that could support itunsourceable— nothing the process emits could support itnot determinable from outside— you are out here, and you cannot tell
In week 10 you do this to your own code, and the third verdict is taken away.
Every transfer this semester is fake#
Which is the point#
A claim about a failure you cannot reproduce is not a claim anybody can check.
The simulator is not a convenience. It is what makes the next eleven weeks falsifiable.
Worked example — four rows of a claims table#
Simulated case, replayed from the course prototype: 40 MB, 99% in nine seconds, then eleven seconds of nothing, then Upload failed.
| Claim | Possible source event | Verdict |
|---|---|---|
| “99%” | progress with loaded/total | sourced |
| bar still shimmering during the 11 s | none — no event fires in that window | unsourceable |
| reaching 99% in 9 s implies ~0.1 s left | derived from the bar’s own rate, not reported | unsourceable |
| “Upload failed” | a server response we cannot see | not determinable from outside |
The shimmer is the interesting row. It is the only claim on that screen that was false for eleven seconds, and it is made without a word.
Your turn — Thursday#
- Setup (20 min). Clone
upload-ui, install, run it, trigger one simulated upload. Raise a problem now rather than in week 3. - In pairs, against one of six supplied recordings of real waiting interfaces.
- Swap — take a recording another pair has done, build your table before reading theirs.
- Everyone names the claim they found least defensible.
Bring the laptop that runs upload-ui.
The mistake to expect#
A table with only text in it.
Motion and absence are claims, and a table that lists three strings and no movement is an incomplete table. It is the commonest way Assignment 1 loses marks on Evidence tracing — 40 of its 100.
The other one: reaching for unsourceable when the honest verdict is
not determinable from outside. From out here you cannot tell a lie from a
shortcut from a constraint you cannot see.
What this week cannot tell you#
Whether any of these interfaces is wrong.
An unsourceable claim is not automatically a bad one. A designer may have had an excellent reason to show a number nobody can justify.
You are recording what is claimed and what could support it. Judgement comes later, and it comes with evidence.
What leaves the room#
- one claims table, with at least one row of each verdict
upload-uirunning on your machine
Where it goes: the table is the method of Assignment 1, due Friday of week 3. The same move, turned on your own code with one verdict withdrawn, is week 10.
Nothing on your screen may assert more than your evidence supports.
That rule applies to your interface, and to everything you write about it.