A choice that waits for the server to agree
Staff tap the day they can work and the button does not change colour until the server says so. In a cellar with one bar of signal that is two seconds of nothing, so they tap again — and set a different answer than the one they meant.
Our staff app has a grid where people say which days they can work. Three choices per day; tap one and it fills in.
It filled in after the server confirmed. Sensible-looking code: send the change, and when it succeeds, paint it. Nothing gets shown that is not saved.
Now picture where a kitchen porter actually opens that screen. A back corridor, a cellar, a stock room with a metre of brick between them and the nearest access point. The tap lands. The button does not move. So they tap again — and on a three-way control, the second tap is not a repeat. It is a different answer.
Paint first, send after
It now changes the instant it is touched, sends in the background, and puts the day back to what it was if the server disagrees — with a line saying so.
The important part is the revert. Painting immediately is easy; the honest version has to remember what was true before the tap, because by the time a failure comes back the screen is showing something else. Get that wrong and you have swapped a slow interface for a lying one.
When this is the right trade
Not everywhere. You would not do it for taking a payment — there, "we do not yet know" is the truth and the screen should say it.
The test we use: if it fails, can the screen quietly put it back? A preference, a toggle, a day in a rota — yes. Anything that moves money, sends a message or tells a kitchen to start cooking — no. Those wait, and say they are waiting.
Most of what staff touch all day is the first kind. It is worth going through your rota and settings screens and asking which is which.