Week 5 Session: Logging the interface

Extending the wait-observation log with a Week 5 field that records what a digital wait's progress or status representation actually did, not just whether one was present.

Four weeks of this log have been about waits that happened to you, reread through whatever mechanism that week introduced. This week extends the same instrument — it doesn’t replace it — with one new field, pointed at a wait a system built on purpose.

Before the session#

Read the Week 5 lecture first. It draws the line this session works from: Week 4 asked whether information was available during a wait at all; this week asks what the specific behaviour of a progress or status representation communicated about the process as it unfolded. Keep those two questions apart, and keep in mind that Harrison et al.’s findings were measured under a short, fixed, controlled duration — not a claim about what you should expect to feel during a real multi-minute wait.

Finding a genuine entry#

Over the week, find one ordinary digital wait with a visible progress or status representation: a percentage bar, a stepped install sequence, a download counter, a countdown, or an indeterminate spinner that makes no positional claim at all. An indeterminate spinner counts — it’s a useful boundary case, since it represents a wait’s state by representing almost nothing about it. Don’t manufacture a wait for this — an app update you were already going to run, a page you were already going to load, a file you were already going to send. Log it in the existing format from Week 1 (Context, Expected wait, Clock duration, Judged duration, Prospective/retrospective, Attending to, Available information, Outcome/notes), and add one new, clearly labelled field:

Describe the behaviour, not just its presence. “There was a progress bar” answers Week 4’s question, not this week’s.

Writing the two-part comparison#

Once you have the entry, write a short comparison in two explicit parts:

1. What the behaviour communicated, partway through — based on what the representation was doing partway through, what did its behaviour seem to communicate about the rest of the wait? (Nearly done, stalled, no basis for any read at all.)
2. What actually happened — did the wait’s ending match that, or contradict it (a bar that looked nearly finished, then stalled; a spinner that offered no basis for any read, and simply ended)?

A worked comparison (a model of the reasoning, not a real observation):

Context: installing a software update, phone in hand, nothing else to do. Expected wait: “a couple of minutes, it usually says.” Clock duration: 3 minutes 40 seconds. Judged duration: “felt like it dragged near the end.” Prospective/retrospective: prospective — I decided to log this one before starting the update. Attending to: the screen, mostly. Available information: a percentage counter. Outcome/notes: relieved when it finally moved past 90%. Interface representation: climbed steadily to about 90% within the first minute, then sat at 90–94% for over two minutes before jumping to 100% in under a second. Communicated partway through: at 90% within a minute, the bar’s behaviour up to that point suggested maybe fifteen more seconds. What actually happened: contradicted it — the stall near the end ran far longer than the rest of the wait combined, then resolved all at once.

Connecting to the lecture, without overclaiming#

Tie your comparison to at least one specific point from this week’s lecture: Harrison et al.’s finding that a pause near the end of a progress bar’s run was reliably perceived as slower in their controlled, fixed-duration comparison, or Myers’s finding that a formal experiment found a significant preference for having an indicator present at all. Say which point your entry is consistent with, or which one it doesn’t seem to fit — one entry can show your observation lines up with, or departs from, a documented pattern; it can’t confirm or refute the finding itself.

In the session#

Bring your entry and your two-part comparison. We compare across the room: whose interfaces climbed steadily and stayed consistent with their own behaviour, whose stalled or jumped against what they seemed to be doing, and what that did to Outcome/notes regardless of clock duration.

What this can and can’t show#

One logged interface, however carefully described, can’t establish that pauses or acceleration have any particular effect on you specifically — it can only tell you whether your own experience of one representation is consistent with what Harrison et al. found in a completely different, controlled setting. Don’t build, delay, or otherwise interfere with an interface to manufacture a more interesting entry; log what you actually encountered. That kind of deliberate intervention belongs to Week 10, not here.

Afterwards#

Keep the log running in this new direction. Week 6 asks the same underlying question of a physical room instead of a screen — what a waiting environment’s own design communicates about how a wait will go — so the next entry you’re building toward doesn’t need a screen at all.