A combination of preview on touch-down and commit on touch-up

What it is

Preview on touch-down and commit on touch-up combines instant feedback with cancellability: contact immediately shows highlighting, a candidate, magnification, or intended effect, while data change or navigation waits for lift. People feel responsiveness yet can inspect and withdraw before commit.

Why it happens

Touch-down enters preview, movement updates preview or cancellation, and lift commits only when validity remains. Preview must be reversible and match the final result; if it already causes external effects, people may believe cancellation still works when it does not. A real engineering trap that later contributors easily introduce by accident: to make the moment of touch-up commit feel "zero latency," an engineer sometimes fires off a network request or warms up a slow operation as early as touch-down, so the data is already ready by the time lift actually commits — a common performance optimization on its own, but one that directly violates this rule's premise. The preview phase is supposed to be purely local, side-effect-free, and freely reversible; the moment it quietly carries an already-dispatched network request, sliding off to cancel only rolls back what is shown on screen, not the request that already hit the server. That optimization and the constraint that "preview must be reversible" now genuinely conflict, and it is usually someone unaware of that constraint who added it later.

Where it stops holding

Preview must not masquerade as commit. Requests, charges, and sends cannot quietly begin at touch-down; continuous controls can update a temporary value while held, but final confirmation and undo rules must remain clear.

Applying it

• Immediately show candidate state through visual, haptic, or audio feedback, distinct from committed state.
• Support exit cancellation and fully restore preview on cancellation.
• How to check: specifically audit the touch-down code path for any network call, analytics event, or other side-effecting invocation triggered ahead of the touch-up commit — this kind of hazard is usually introduced later as a performance optimization, not present in the original interaction design.

Related

• Same group: C2.07.1 Touch-up activation allows changing one’s mind mid-action · C2.07.2 Touch-down activation responds faster but cannot be cancelled · C2.07.3 Irreversible actions must use touch-up activation
• Nearby: D1 Output and feedback channels · C2.08 Touch cancellation gestures
• Search terms: preview · touch up · commit