Where data is born

Every chart the manager reads and every decision the supervisor makes starts with an operator entering something: a measurement, a reason for a stop, a tick on a checklist. On paper, a smudged number is caught later, if at all. On a screen, a mis-tap is caught never, unless the screen was designed so the mis-tap cannot happen.

Session 10 starts Unit 3, the three surfaces. The operator surface comes first because it feeds the other two. The supervisor review and the manager view (Session 11) can only be as good as what the operator surface records.

The task you will build

Acme's press shop in Cleveland (an illustrative plant used throughout the course) checks the first bracket off Line 3 after every die change. Today it is a paper sheet on a clipboard: part number, three measurements, pass or fail, initials. You will build the screen that replaces it: scan the press, see the part and its limits, enter three numbers with a keypad, submit. It must work with gloves, at arm's length, and in the dead spot behind Press 04 where the wi-fi drops.

How it is scored

The element is complete when you have opened every chapter and taken the assessment, and passed at 80% or more. You can retake the assessment.

Why 44 pixels

Apple's design guidance gives 44 by 44 points as the minimum size for a control people tap ^[1]. Android's accessibility guidance asks for 48 by 48 density-independent pixels ^[2]. The web's accessibility standard, WCAG 2.2, sets 24 by 24 CSS pixels as the minimum at level AA and 44 by 44 at the stricter level AAA ^{[3] [4]}. On a phone, 44 CSS pixels is about 7 millimetres. A bare adult fingertip is wider than that, so even 44 is a minimum, not a target ^[5].

Gloves change the numbers. Many work gloves do not register on a capacitive touchscreen at all; touchscreen-compatible gloves do, but they make the contact patch bigger and less precise. The course rule: 44 px minimum everywhere, 64 px for the main actions on any screen used with gloves, and at least 8 px of empty space between targets so a wide contact does not hit two at once. Test with the gloves your operators actually wear.

Fitts's law

In 1954 Paul Fitts showed that the time to hit a target grows with the distance to it and shrinks with its width, following a logarithm of their ratio ^[6]. The modern form used in interface design is the index of difficulty, log2(D ÷ W + 1), measured in bits. Each extra bit adds roughly the same time. Halve a target's width and you add about a bit; and with time pressure, people trade speed for accuracy, so the miss rate climbs.

Two design rules follow. Make the action people take most often the biggest target on the screen. And put it where the thumb already is: at the bottom, full width, on a phone or a tablet held in one hand.

One task per screen

An operator mid-shift gets interrupted. A screen with one job, named in plain words at the top, can be picked up again in a second. A screen with six tabs and a sidebar cannot. The operator surface is not a smaller copy of the manager view; it is a different tool.

<label for="flange">Flange height (mm) <small>limits 24.80 to 25.20</small></label>
<input id="flange" name="flange_mm" inputmode="decimal" autocomplete="off" required
       style="font-size: 20px; min-height: 64px; width: 100%">
<button type="submit" style="min-height: 64px; width: 100%">Submit check</button>

Size for the distance

How readable a letter is depends on the angle it fills at the eye, not on its size in pixels. Human factors standards for workstations express character height as a visual angle, with roughly 16 minutes of arc as a minimum and 20 to 22 minutes preferred for comfortable reading ^[1]. A minute of arc is one sixtieth of a degree.

At 22 minutes of arc the height you need is about the distance divided by 156. That gives the numbers below, for capital letters. Lower-case letters are smaller than capitals, so this is the floor for anything an operator must read, not a target for headings.

Contrast

WCAG 2.2 requires a contrast ratio of at least 4.5 to 1 between normal text and its background, and 3 to 1 for large text ^[2]. The enhanced level asks for 7 to 1 ^[3]. On the floor, glare, dust on the screen and safety glasses all lower the contrast the eye actually receives, so aim for the enhanced level on the operator surface. Thin grey text on white is the most common failure; it looks elegant in an office and disappears under a skylight.

Calm until abnormal

Control-room practice learned this the hard way. Screens covered in bright colours and moving graphics make it harder, not easier, to spot the one value that matters. The ISA-101 standard for HMI design and the high-performance HMI practice behind it recommend muted, mostly grey screens where colour is reserved for abnormal conditions, so that colour always means something ^{[4] [5]}. The same holds for a first-off check: the screen is quiet while values are inside the limits, and a value outside them is the only thing in colour, with a word that says what is wrong.

What goes wrong without it

A plain web form sends the entry when the operator taps Submit. If the network is down, the browser shows an error and the entry is gone, or the operator taps again and again. Worse is the half-failure: the entry reaches the server, but the reply is lost in a dead spot, so the tablet thinks it failed and sends it again. Now the check is recorded twice, and the first-pass yield is wrong.

The outbox pattern

The fix is the same pattern the platform uses for email and texts (write first, then send), applied on the device:

1. When the operator taps Submit, the screen creates an id for the entry on the device, with crypto.randomUUID() ^[1], and saves the entry with its id in an outbox in the browser's IndexedDB storage, which survives a reload or a closed tab ^[2].
2. The screen confirms at once: Saved on this tablet. The operator moves on.
3. A small sender loop tries to post each outbox entry to the server. When the server replies saved, the entry is removed from the outbox.
4. If the post fails because of the network, the entry stays and the loop tries again later, waiting a little longer each time (backoff).
5. The server inserts the entry using the id as the primary key and ignores a second insert with the same id. A retry can never create a second row.

-- The server side: the id comes from the tablet; a second arrival with the same id changes nothing.
insert into first_off_checks (id, line, press, part, hole_mm, flange_mm, burr_ok, entered_by, entered_at)
values ($1, $2, $3, $4, $5, $6, $7, auth.uid(), $8)
on conflict (id) do nothing;

Postgres's on conflict do nothing clause makes the insert safe to repeat ^[3]. Payment providers use the same idea, called an idempotency key, so that a retried payment is never charged twice ^[4]. The server still checks everything else as usual: the operator is signed in, the matrix lets their role write first-off checks, and the values are in range. A retried entry that is refused is refused every time.

Tell the operator the truth

The browser's navigator.onLine says only whether the device has a network connection, not whether the server can be reached ^[5]. So do not show 'online' from it. Show what matters: how many entries are waiting in the outbox. All sent in small grey text when it is empty; 3 waiting to send in amber when it is not.

A refusal is different from a network failure. If the server says the value is out of range or the operator's role cannot write this record, retrying will not help. Keep the entry, show it to the operator with the server's reason in plain words, and let them fix or discard it. Nothing in the outbox is ever deleted silently.

Load the screen with no network

An outbox does not help if the screen itself cannot load. A service worker is a small script the browser runs alongside the page; it can keep a copy of the screen's files and serve them when the network is down ^[6]. Cache the operator screen's code and the reference data it needs (the parts and their limits for this line), and refresh them when the network is back. Keep it small: the operator surface needs one or two screens offline, not the whole platform.

Test it offline

test("a first-off check entered offline is sent once when the network returns", async ({ page, context }) => {
  await page.goto("/operator/first-off?press=L3-P02");
  await context.setOffline(true);
  await page.getByLabel("Flange height (mm)").fill("25.02");
  // ... fill the other fields ...
  await page.getByRole("button", { name: "Submit check" }).click();
  await expect(page.getByText("1 waiting to send")).toBeVisible();
  await context.setOffline(false);
  await expect(page.getByText("All sent")).toBeVisible();
  expect(await countRows("first_off_checks", { press: "L3-P02" })).toBe(1);   // exactly one, never two
});