Kiosks & Operator Terminals
Designed for the person who has thirty seconds.
A floor terminal is judged by whether it slows anybody down. That makes the hardware a design decision rather than a purchasing one: screen size, mounting height, glove-compatible touch, glare, and whether a scanner is a better input than a keyboard all change what the interface can be. We specify and deploy the physical side alongside the software division building what runs on it.
- Operable without taking them off
- Gloves onOperable without taking them off
- Boots into the application, stays there
- Single purposeBoots into the application, stays there
- When the network does not
- Keeps workingWhen the network does not
Sounds like
You might recognise one of these.
Nobody uses the terminal. They write it down and enter it later.
The screen is unreadable where it is mounted.
Operators are taking their gloves off to use it, so they stopped using it.
We bought tablets and half of them have already been dropped.
What this includes
The work, specifically.
Not every engagement needs all of it. This is the range we cover and what each part is actually for.
Hardware selection for the environment
Brightness for the lighting that is actually there, glove-compatible or gloveless touch, ingress rating for wash-down or dust, and a mounting position established by standing where the operator stands.
Input that suits the task
Barcode, RFID, scale, weight or a physical button, chosen because it is faster than typing for that specific action. Most floor tasks should not require a keyboard at all.
Kiosk lockdown
A device that boots into one application, cannot be navigated out of, and recovers to that state after a power cut without anybody logging in.
Offline behaviour
What the terminal does when the network is gone, which is the state that decides whether the floor keeps working or stops.
Mounting, power and cabling
Specified and coordinated, including the parts that need an electrician. Most terminal projects stall here rather than on software.
What you get
Deliverables, not documents.
- Specified hardware with the environmental reasoning behind each choice
- Mounting and power plan, coordinated with your trades
- Locked-down device image that boots into the application
- Defined offline behaviour, tested by disconnecting the network
- A spares and replacement path
Shapes
How this usually runs.
Floor study and hardware specification
2–3 weeksWatching the task performed, timing it, and specifying hardware against what we observed rather than against a datasheet.
Pilot terminals
4–8 weeksA small number in place, in use, with the operators who will live with them.
Rollout
OngoingThe remaining positions, with spares and a replacement process.
Tooling
What we build it with.
No tool here was picked because it was new. Where we do reach for something novel, it is in one place, for a stated reason, and it is written down.
- Devices
- Input
- Management
Questions
Terminals, honestly.
The software division does, and we work as one team on it — that is the point of specifying the hardware and the interface together. If you already have the application and only need the physical side deployed, that is a smaller engagement and we are happy to scope it.
Whichever survives your environment at the lower total cost, and the honest answer is often consumer hardware plus a good case. We price the replacement rate rather than assuming industrial is automatically correct.
The device returns to the application without a person logging in, which is a requirement rather than a nicety on a floor where nobody has the password.
Next step
Tell us what’s breaking.
Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether you should be building this at all.