Week 1 Studio: What does 99% promise?

The opening autopsy. Take a waiting interface you did not build, list every claim it makes, and find the ones that cannot have a source.

25 February 2027

Here is the case for this week, and you have almost certainly lived it.

You attach a 40 MB video to a web form. A bar fills smoothly to 99% in about nine seconds, then stops. The percentage does not change for eleven seconds. The bar keeps animating — a soft diagonal shimmer moves across it the whole time. Then the page says Upload failed. Please try again.

Something in that sequence was untrue. This week you work out what, and more usefully, you work out which parts you are in a position to judge from the outside at all.

By the end of this week#

You can:

• list every claim a waiting interface makes, including the ones made by motion and by silence rather than by text;
• for each claim, name an event the underlying process could emit that would support it, or say that none could;
• tell the difference between a claim that is false and a claim you simply cannot check from outside the system, and say which one you are looking at;
• run the course prototype and trigger a simulated upload.

The idea#

Tuesday’s lecture, What 99% Promises, sets up three terms. They are the whole method, so they are repeated here.

A claim is anything a reader can take from the interface. The obvious ones are numbers and words. The less obvious ones matter more:

• motion — a bar that shimmers while nothing else changes is claiming the process is alive. In the case above, that claim was false for eleven seconds and nothing in the text said so.
• rate — a bar that reaches 99% in nine seconds implies the last 1% takes about a tenth of a second. It took eleven.
• absence — a screen that shows no error is claiming there is nothing to report.

A source event is something the process reports, at a moment you could write down. This is the distinction people slide off. A server writing bytes to disk is something the process does; progress: 4.2 MB of 11 MB is something it reports. Only the second can support a claim on a screen. Most invented progress lives exactly in that gap: a real activity with no corresponding report, filled in with an animation.

A verdict pairs the two. You have three this week:

The third verdict is not a cop-out; it is the honest majority of a black-box analysis, and using it correctly is a marked skill. In week 10 you do this exercise again from inside your own code, and that verdict is withdrawn.

View this week’s slides — Tuesday’s lecture deck. Worth a pass before the studio, and the reference while you build. On a phone they are small — the deck is built for a projector, and this page carries the same material as prose.

In the room#

Thursday 25 February, 14:00–17:00.

What you start with#

• upload-ui, cloned and running locally. If it does not run, say so in the first twenty minutes rather than in week 3.
• Six screen recordings of real waiting interfaces, supplied in materials/week-01/. Each is under 30 seconds.
• A blank claims table, as a markdown file you will keep adding to.

What you build#

A claims table for one recorded interface, one row per claim:

A worked example#

Four rows from the case above, to show the shape:

The shimmer row is the interesting one: the only claim on that screen that was false for eleven seconds, and it was made without a word.

Done when#

• Every claim visible in your recording has a row. Pause the recording and scan the screen; anything that changed is a claim.
• No row is blank. “I don’t know” is spelled not determinable from outside.
• You have at least one row of each of the three verdicts, or you can say why the recording genuinely had none of that kind.

The mistake to expect#

A table with only text in it.

Motion and absence are claims. A table listing three strings and no movement is an incomplete table, and it is the commonest way Assignment 1 loses marks on Evidence tracing — 40 of its 100.

The second: reaching for unsourceable when the honest verdict is not determinable from outside. From outside you cannot tell a lie from a shortcut from a constraint you cannot see.

Before next week#

About two hours.

1. Finish the table if the room ran out of time.
2. Watch your own machine do something slow — an OS update, a large download, a phone backup — and write down three claims it makes. No table needed; a list is enough. Bring it to week 2.
3. Read the two NN/g pieces below. They are short.

If you are joining late#

Not applicable — this is week 1. But upload-ui has a stage-01 tag, and every later week has its own. A stage checkpoint is a floor, not an answer: it restores the mechanism the next week needs and leaves every judgement in it unmade.

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 — a legal requirement, a platform default, a constraint you cannot see from out here. From outside the system you cannot distinguish a lie from a shortcut from a limitation.

You are recording what is claimed and what could support it. Judgement comes later, and it comes with evidence.