Touch-up activation allows changing one’s mind mid-action
Aliases: touch up · cancellation · change of mind
What it is
Touch-up activation commits only when a finger lifts, so people can inspect feedback after press, move outside the target or into a cancel area, and lift to abandon. Press is a reversible candidate stage, leaving recovery space for a mistake or hesitation.
Why it happens
Press enters a pressed state, movement updates candidate or cancellation, and lift decides commit from current location. This press–check–lift loop was not invented for touchscreens out of nowhere — it inherits an intuition already established by physical buttons: a doorbell, an elevator floor button, a mechanical switch all let someone change their mind after pressing down and before truly releasing, simply by sliding a finger off the button while still holding it down and releasing outside its bounds. Nearly every platform's standard button widget implements exactly this state machine by default, which means people's expectation that "holding down still lets me back out" has been confirmed repeatedly by every other native button on the device — no single control taught them this individually. The moment a custom control fails to replicate this behaviour, people bring that generalized expectation to it, find sliding off does not cancel, and experience it as the control being broken rather than "just designed differently."
Where it stops holding
Touch-up adds a confirmation moment over touch-down, so continuous, low-risk, or instant-response actions may not need it. Cancellation also cannot rely on tiny or hidden regions. This state machine should not be applied blindly to every touch interaction either: contexts that need continuous feedback from the very instant of contact — a brush touching down on canvas, say — would feel sluggish under a "only lift counts" rule. Whether to use touch-up depends on whether the interaction genuinely benefits from a candidate-then-change-your-mind stage, not on treating it as the default answer for every button.
Applying it
- Keep pressed, candidate, and cancel states visible for ordinary buttons.
- Permit exiting to cancel and re-entering to restore candidacy.
- How to check: test every custom, button-looking component in the app for whether sliding off actually cancels it, using native platform buttons as the behavioural baseline, and identify which custom components violate the expectation people already carry with them.
Related
- Same group: C2.07.2 Touch-down activation responds faster but cannot be cancelled · C2.07.3 Irreversible actions must use touch-up activation · C2.07.4 A combination of preview on touch-down and commit on touch-up
- Nearby: C2.08 Touch cancellation gestures · D1 Output and feedback channels
- Search terms:
touch up·cancellation·pressed state