A progress bar is a promise made under uncertainty. Twelve weeks on one file-upload interface: what it may claim about progress, time remaining and completion, and what it has to admit it cannot know.
Every upload bar you have ever watched was lying to you, and most of them were lying for good reasons.
The system does not know how long this will take, and it has to say something anyway. This course spends a semester on that one sentence.
It is not a course about UX. It is a course about the twelve inches of screen between a user pressing Upload and finding out whether it worked.
What you will do
The whole semester is one artefact. In week 1 you inherit a file-upload interface that sits at 99% for eleven seconds and then fails silently. By week 12 it tells the truth — including when the truth isI don’t know.
Everything in between is you finding out what your interface actually has evidence for: bytes, stages, elapsed time, an estimate, or nothing at all. You will build a state model and discover it was wrong. You will write three time estimators and measure how much each one lies to itself. You will turn the animation off and find out whether it was carrying information. You will watch three people use the thing and resist the urge to change everything they touched.
No server is involved. Every transfer, stall, timeout and dropped connection is simulated locally, so you can reproduce any failure on demand. That is the thing you can never do with a real network, and it is the reason this subject can be taught at all.
The bar says 99%. What is left?
That is the whole course, and it has an answer. Three different things are usually being confused, and an interface that keeps them apart stops needing to sit at 99% at all.
- The percentage
- A fraction, and a fraction needs a denominator. Most bars count bytes handed to the network. On a fast connection that finishes early, and everything after it — hashing, checking, storing — is outside the number.
- The stages
- What the process is actually doing: read, hash, transfer, verify. A bar counting bytes is blind to three of those four. A bar counting stages sees all of them and moves in lurches, because the stages are not the same size.
- The completion condition
- The sentence that says when the interface may claim done. “The last byte left this machine”, “the service acknowledged it” and “it would survive a power cut” are three different sentences, seconds apart, and only the last one is what the user came for.
A bar stuck at 99% is usually a denominator that ran out.The transfer it was counting has finished; the work the user is waiting for has not; and the interface has no vocabulary for the difference. Twelve weeks on that.
See it happen
The progress simulator runs the five behaviours this course works through — a steady upload, stages at different speeds, an upload with no known total, a stall that recovers, and a failure you can retry. Everything in it is simulated in your browser; no file is read and no request is made.
The one worth a minute is “Stall, then recover”. Here is what it does, so the page is worth reading even if you never press Start:
- The bar advances normally to 45% — 45 of the 100 work units the four stages are worth.
- Then the transfer stops reporting. The bar freezes and stops animating entirely, because a moving bar would be claiming something is happening when nothing is.
- The elapsed counter keeps running. That, and not an error, is what tells you something is wrong — a counter reading 0:45 on a job that normally takes 0:06 has communicated a problem with no error handling at all.
- Eight seconds later the transfer resumes on its own and the bar picks up from 45%.
- It reaches 100% only when a
committedevent arrives — not when the bytes finish. The page prints that condition next to the bar, which is the standard every student prototype is held to.
There is a ×4 speed control. A site about waiting should not make you do any.
How it runs
Twelve weekly studios, three hours each, and four lectures. The lectures are set pieces: each one introduces something you could not work out at the machine, and the studio two days later applies it. The other eight weeks open with a short framing and then get out of the way.
Who it is for
Second-year students who can write HTML and CSS and enough JavaScript to write a function that takes a callback. You will not need a background in psychology, and you are not permitted to cite one you do not have.
What this course is not
- Not a general interface design course. One widget, one interaction, twelve weeks.
- Not a psychology course. We read what the published work on perceived duration claims, and then we fail to replicate it in a room of twenty classmates, on purpose.
- Not a course about making users feel better. Sometimes an honest interface is the more irritating one. That trade is the subject.