The Optimistic Toggle That Changed State Three Times
A Glimpse toggle tried to feel immediate, then moved through three visible states when its local guess collided with authoritative service updates.
An optimistic toggle in a Glimpse prototype appeared to activate, deactivate, and activate again after one click. The service eventually reached the requested state, but the UI exposed every disagreement between its local guess and the authoritative event stream.
The prototype was later removed, so this is an account of a failed interaction design rather than a shipped fix. It is still useful because the three transitions reveal exactly where optimistic UI becomes unstable.
One control had two writers
The click handler immediately set local state so the control would feel responsive. It then sent a command to the service. Meanwhile, the widget remained subscribed to service snapshots and rendered each one as authoritative.
The sequence looked like this:
- Local activation: the click handler changed the toggle before the command completed.
- Old snapshot: an already queued or intermediate service update rendered the previous value.
- Confirmed activation: the service applied the command and published the new value.
Each individual write made sense. Together they produced a visible reversal because the UI had no rule for distinguishing a stale snapshot from a rejection.
"Set local state and wait" still needs a protocol
The tempting fix is to keep the optimistic value until the service publishes the same value. That works only if several cases are defined. What happens when the command fails? How long does the local value remain pending? What if another client changes the state? Can snapshots be ordered relative to commands? Does the service echo a command identifier or generation?
Without an ordering marker, the widget cannot know whether a disagreeing snapshot predates its command or represents the service's final answer. Ignoring disagreement for a timeout hides real external changes. Accepting every snapshot recreates the flicker.
A small protocol addition can make optimism sound: attach a monotonically increasing generation or command ID, publish it with the resulting snapshot, and keep the local value pending only until that command is acknowledged or rejected. If the service cannot provide that contract, pessimistic rendering is often the more truthful interface.
Immediate feedback does not require pretending the value changed
The control can acknowledge the click without displaying an unconfirmed state. It can show a pending treatment, temporarily disable repeated input, or animate the request while leaving the last confirmed value visible. Those choices tell the user that work is happening without claiming success.
For a local desktop service, the round trip may be short enough that the simplest answer is to wait for the published state. Optimism should solve a measured latency problem, not be added by reflex.
The removed prototype left a clear rule for future Glimpse controls: a value with multiple writers needs an ordering contract before the UI predicts it. Otherwise the animation is fast, but the truth arrives three times.