Designed on a desk, operated in a glove

An operator terminal is almost always designed somewhere comfortable. The developer sits at a desk with a color-accurate monitor, indoors, at a fixed distance, with bare hands and as long as they need. The screen looks good, the interactions feel right, and the review happens under the same conditions, which is why it passes.

Then it is mounted next to a machine. The operator is standing, sometimes two meters back, wearing whatever the job requires on their hands. The light is a skylight at three in the afternoon or a single fixture at night. Their attention is properly on the equipment rather than on the display. None of the conditions the design was validated under still holds, and the screen is judged by whichever one broke hardest.

How big does a target have to be?¶

Bigger than the published floor, and the floor is a useful place to start because it is specific. WCAG 2.2 (opens in a new tab) sets Success Criterion 2.5.8, Target Size (Minimum), at Level AA: "the size of the target for pointer inputs is at least 24 by 24 CSS pixels", with a small set of exceptions for spacing, inline targets and cases where the size is essential.

That number was set for a bare finger or a pointer under ordinary conditions. Its own supporting material is explicit that the benefit extends to people with dexterity limitations, and to "people using a device in environments where they are exposed to shaking such as public transportation". A plant floor is that environment with extra steps. Treat 24 pixels as the number below which a target is indefensible, not as the size to draw.

Two things matter more than the nominal size and are easier to get wrong. Spacing, because an adequately sized target adjacent to another one is still a mis-tap waiting to happen, and the criterion's own exceptions turn on spacing for exactly that reason. And consequence: a control that starts or stops equipment should be separated from everything else by distance and by shape, so that a wrong press is physically awkward rather than merely regretted.

Will the glove work on the panel?¶

Sometimes, and the answer depends on the specific glove rather than on gloves in general, which makes it a specification to capture rather than an assumption to carry. A thin nitrile glove usually works on a capacitive panel because it does not meaningfully interrupt the coupling. A thick insulated glove, a leather rigger, or a nitrile glove that is wet or contaminated frequently does not, and the failure is intermittent rather than total, which is the worst kind: the operator presses twice, then harder, then decides the screen is unreliable.

This is worth settling before a panel is bought rather than after it is mounted. Ask what is on the operator's hands on the worst day, get a pair, and test the actual hardware with them. Where the answer is that the glove will not work, the options are a panel with a glove mode, a resistive or infrared touch technology, or physical controls for the small number of actions that have to work every time. All three are cheaper than a screen people stop trusting.

Light is the other environmental input that gets assumed. A display specified for an office is not a display for a south-facing bay, and the failure shows up first in exactly the place you least want it: a state indicated by color alone washes out, while text remains readable, so the screen looks fine and the status is gone.

What does the screen say when nobody is touching it?¶

The most valuable property of an operator terminal is that the machine's state is readable from where the operator stands without touching anything. Their attention belongs on the equipment. A screen that has to be interrogated, navigated or woken competes for that attention at exactly the moments when it is most expensive to take.

That has a few concrete consequences. State is carried by position and shape as well as color, so that it survives glare, an angle and a color-vision deficiency. Running, stopped, faulted and waiting-for-input are distinguishable across the room rather than on inspection. And whatever the operator needs most often occupies the place their eye already goes, which is discoverable by watching somebody work rather than by reasoning about it.

Alarms are the same argument at higher stakes. A screen that raises an alarm for every condition trains the operator to clear alarms without reading them, and once that habit exists it applies to the alarm that mattered. An alarm the operator cannot act on is not a safety feature; it is a tax on the ones they can. The test for each is whether there is an action, and whether that action is available from where the alarm appears.

Is a consumer tablet ever the right answer?¶

Often, and the reflex to specify industrial hardware for everything is worth resisting because it is expensive and sometimes buys nothing. A tablet in a protective case, on a clean bench, in a climate-controlled room, operated with bare hands, is a good screen at a fraction of the cost, with better resolution and a maintenance path any local supplier can service.

The conditions that rule it out are specific rather than a matter of seriousness. Washdown, where the enclosure rating is the requirement and a case is not one. Temperature outside the commercial range, which is common in an unheated building in winter and in a bay in summer. Sustained vibration, which degrades connectors and mounts rather than screens. Long service life, because a consumer device has a support horizon measured in a few years and a machine has one measured in decades, and that mismatch is the most commonly underestimated cost in this decision.

Where none of those applies, buy the cheap screen and spend the difference on the software. Where one of them applies, the industrial panel is not a luxury and the specification should say which condition is driving it, so the next person understands what they are allowed to change.

The walk-up test¶

One test settles more arguments than every review conducted at a desk, and it takes twenty minutes. Take the built screen to the place it will live, at the worst time of day for light, and hand it to somebody who did not build it, wearing the gloves they actually wear.

• From where they stand, without touching anything, ask them what the machine is doing. If they have to approach or interact to answer, the state display has failed and nothing else on the screen matters yet.
• Ask them to perform the three most frequent actions. Count the mis-taps rather than asking how it felt, because people are polite about interfaces and accurate about their own errors only when they are being counted.
• Raise a real alarm condition and watch what they do first. If they clear it before reading it, the alarm design is the finding, not the operator.
• Then take the screen away and ask what they would change. The first thing said is worth more than the rest of the session.