Waiting Interface Prototype

The first half of the semester, shipped — a determinate bar, an honest estimate, an indeterminate case with no fractions, and an accessibility audit that records its failures.

Due: 27 April 2027 · Weight: 30%

The brief#

Ship the interface you have been building since week 2, and audit it against the standard published in week 2.

Why it is due on the Tuesday of week 8#

The accessibility work is taught on Tuesday 20 April (lecture) and practised in the week 7 studio on Thursday 22 April, with tutors in the room. This falls the following Tuesday at 10:00 — five days later, across a weekend and a public holiday.

The Waiting Interface Checklist v0 was published in week 2, but publishing a standard is not teaching it, and it carries no marks before now. The gap between the last teaching and this deadline is what makes the audit criterion fair.

There is no class on the day this is due, and the week 8 studio on the Thursday is not shortened for it.

What Assignment 1 gives you#

This is not a second attempt at the autopsy. It is the first time the same reasoning is applied to something you built.

• the claims table method becomes Evidence discipline — you are now the designer whose numbers get traced
• the state model you inferred from outside becomes the one you own, and condition (d) asks you to publish its completion criterion
• the limits section becomes the audit sheet, where “fail” is a scoring answer

What you submit#

The deployed prototype, plus an /audit/ page in the repository.

The prototype: four conditions from one interface#

Each must be reachable by a marker from your exposed simulator controls, without reading your code.

(a) Known size, determinate. A bar driven by real progress events, with the denominator named on screen — “bytes sent, excluding server-side verification”, not “upload progress”.

(b) Time remaining. A readout naming, on the page, which estimator, what rounding, what refresh interval. Any of the three from week 5 is acceptable. Being unable to say which one you shipped is not.

(c) Unknown size. No fractional reading anywhere — not in the bar, the text, the document title, or the favicon. Use one or more of the three registers from week 4.

(d) Completion. The criterion for claiming completion is stated where a user can read it, and the interface only claims completion when that criterion is met.

The audit page#

Checklist v0 completed, plus the week 7 audit sheet: keyboard path, progressbar semantics, live-region behaviour, reduced-motion variant. Each line marked pass / fail / not applicable, with the evidence that settled it.

A worked example#

The four conditions are marked on what a marker can read on your screen, not on what your code does. Here is the same prototype, in the four states, with the sentences that make each one gradeable:

Each of the four italic lines is the part being marked. Without it, (a) is a number with no denominator, (b) is a guess with no method, and (d) is a word that could mean three different things.

And the audit sheet, in the form that scores — one line, recorded honestly:

Line 2 — semantics     FAIL   aria-valuenow="0" during the unknown-size case
                       fixed  removed it; added aria-valuetext
                       re-checked by listening: "transferring, total unknown"

The mistake to expect#

A condition that works but cannot be triggered.

Every year, someone builds all four correctly and exposes controls for three of them. A marker cannot distinguish a condition they cannot reach from one that does not work, and it is marked as the second. Before you submit, hand the URL to somebody who has not seen your code and ask them to reach all four. If they need a hint, the controls are not exposed.

The second: an unverifiable pass on the audit sheet. A line recorded honestly as a failure scores. A pass your marker can break does not, and costs more than the failure would have.

How the criteria are read#

Behaviour across the four conditions (35). A marker reproduces all four using your controls. A condition that works but cannot be triggered scores nothing, because the marker cannot tell it apart from one that does not work.

Evidence discipline (25). Nothing on screen implies precision the state does not support. Specifics that get checked: a percentage displayed to one decimal place from an integer-valued source; a time estimate refreshing faster than it can be read; a fraction surviving in the tab title during condition (c).

Accessibility audit (25). Honesty is the scored property. A line recorded as a failure scores. A line recorded as a pass that your marker can break does not, and costs more than the failure would have. Four passes with no notes reads as an audit that was not run.

Both viewports (15). Bar, text and controls all work at 1920×1080 and 390×844. The usual failure is a control row that wraps behind the bar at 390px, which is invisible until you look.

Where this goes#

Again, nothing is resubmitted. Assignment 3 marks different things about a changed artefact:

The criteria do not repeat: Behaviour across the four conditions is marked here and never again, and Behaviour under abnormal conditions is marked in A3 and not here. A prototype that is unchanged between the two will score on neither.

What is not assessed here#

Estimator accuracy — week 5 is practice, and the honest answer is often that your estimator is poor. Motion preference from week 6. Failure states, cancellation and retry: those are week 8 onward and belong to Assignment 3.