Tensions in Practice: Perceived responsiveness in tension with confirmed state¶
Interface updates · delayed replies
After a user requests an edit, the interface can wait for the server’s reply or show a predicted result immediately. The preview makes the interaction feel faster, but the underlying request is still unresolved. If the server rejects or changes it, the interface must reconcile what it already showed. A responsive display is useful; it is not itself confirmation.
Keep interaction responsive
Let the user see an immediate, intelligible response to an action.
Represent what is confirmed
Avoid presenting a prediction as an authoritative completed change.
Why these aims pull against each other
A local preview can hide waiting from the display but cannot eliminate the underlying delay or the possibility of contradiction.
Choose an arrangement to see what changes and what remains difficult.
Qualitative paths and conditions, not measured costs, timings or performance guarantees.
What this choice protects
What it costs
When it fits
Compare the arrangements
Wait for confirmation
Show that the request is pending, then display the authoritative result.
- What it protects
- A changed state is not presented as complete before its result is known.
- What it costs
- The user waits through the full delay to see the confirmed change.
- When it fits
- The consequence of acting on a wrong preview is high, or reconciliation would be confusing or costly.
Illustration note: The pending display is an editorial interface choice. Waiting for a reply does not guarantee the server’s substantive correctness.
Show a provisional preview
Display a clearly provisional local prediction, then confirm or correct it when the reply arrives.
- What it protects
- The interaction can feel immediate while the underlying request travels.
- What it costs
- A contradiction requires correction or rollback, and premature reliance can compound the error.
- When it fits
- The operation and downstream interactions can tolerate reconciliation, and users can distinguish pending from confirmed state.
Illustration note: Explicit provisional labeling is editorial judgment addressing the source’s concern about confident action on guesses. No particular interface implementation is prescribed.
What this illustration does—and does not—establish
Latency: Hiding latency improves the felt experience but can deepen the underlying danger supplies prediction, apparent responsiveness, and rollback risk. The split and rejoin show what is still unresolved while the display changes.
- A prediction and an old confirmed value are different: speculation can be wrong even when no stored value is stale.
- This is an interface arrangement, not a protocol guaranteeing successful rollback or exactly-once effects.
- No prediction accuracy or latency improvement is quantified.
Source entries
Latency
Latency: Hiding latency improves the felt experience but can deepen the underlying danger supplies the conflict examined here.
Hiding latency improves the felt experience but can deepen the underlying danger
T3: Hiding latency improves the felt experience but can deepen the underlying danger. Prediction, speculative execution, optimistic UI updates, and buffering can make a high-latency system feel responsive by showing a guessed or pre-fetched result before the true one arrives. This genuinely improves usability, but it also conceals the real delay from the operator and can produce confident action on information that is even more speculative than stale data. When the prediction is wrong, the system must roll back, and the masked latency reasserts itself, often at the worst moment. The tension is between making the delay invisible and keeping the operator honest about acting in the dark.