Course overview

What the course studies, who it is for, what you make, and how the twelve weeks are put together.

What it studies

One widget. A file-upload waiting interface, and the question of what it is entitled to say while the upload is in flight.

That sounds small and it is. The narrowness is the design: a progress bar is where a system's uncertainty about itself becomes something a user reads, and a semester is about the right length to work out how much of what a typical one says is supportable. The course spends twelve weeks moving one interface from two states and a shimmer to something whose every displayed number can be traced to an event.

Who it is for

Second-year students who can write HTML and CSS, and enough JavaScript to write a function that takes a callback and to reason about a promise. That is the whole prerequisite.

You do not need a background in psychology, statistics, or human-computer interaction. Where the course touches published work on perceived duration it links the work and says what it measured; where it has no evidence it says so. You are not expected to arrive with an opinion about design.

What you make

Everyone starts from the same deliberately broken prototype, upload-ui: two states, one of which is a lie, and a bar that sits at 99% for eleven seconds before failing silently. You keep the same repository for twelve weeks.

By week 12 it handles known and unknown durations, names its own denominator and estimator on screen, survives a stall, a timeout and a disconnection with messages that say what happened to the file, keeps written guarantees for cancel and retry, works from the keyboard and with motion off, and ships with a register of every claim left on its screen.

Every transfer is simulated locally. No server is involved at any point, which is what lets you reproduce a stall on demand — the thing you can never do with a real network, and the reason the subject is teachable at all. You can try the same mechanism on the progress simulator.

Learning outcomes

At the end of the course you can:

LO1

Trace each claim a waiting interface makes — a percentage, a time, a word, a motion — to the event in the underlying process that could support it, and mark the ones that have no possible source.

LO2

Implement a file-upload waiting interface that behaves correctly under known duration, unknown duration, stall, timeout, disconnection, cancellation and retry, using a local simulator.

LO3

Audit and repair a waiting interface's keyboard path, status text and reduced-motion behaviour against a stated checklist, recording failures as failures.

LO4

Justify a design decision from evidence you actually gathered, and state a conclusion no stronger than that evidence supports — including deciding, with reasons, not to change anything.

Every week page names the outcomes it teaches, and every assessment names the outcomes it assesses. Nothing is assessed that a studio dated before the deadline has not taught — that is checked mechanically rather than promised.

How the semester runs

12 studios, 4 lectures, one artefact.

• Studios — Thursdays, 14:00–17:00, every week. Three hours at the machine on the same prototype.
• Lectures — Tuesdays, 11:00–12:00, in weeks 1, 4, 7 and 11 only. Four, not twelve. Each carries something you could not arrive at at a keyboard, and the studio two days later applies it. The other eight weeks open with a framing and a set reading in the studio itself, named on each week's page.
• Between studios — two to three hours. Each week page ends with a Before next week section that says what and how long.

If you miss a week, each studio has a stage checkpoint (git checkout stage-07) that restores the mechanism the next week needs and leaves every judgement in it unmade. A floor, not an answer: you can rejoin without having finished the week before.

Assessment

There is no examination. Each piece assesses what came before it and nothing that comes after, and the third is largely assembled from work already done in weeks 10 and 11.

Where to go next