The danger of a full swipe that executes immediately

What it is

One grade of row swipe is “drag past the whole row, lift, and the default revealed action runs,” with no extra tap on a button. That grade is full-swipe-to-perform. It saves a tap and also removes a confirmation. Inertia, a neighbor-row miss, or overshooting a reveal will all commit at lift. The danger is that commit is bound to travel, not to an explicit tap.

Why it happens

Revealing buttons is two-stage: slide (choose which commands to see) then tap (commit one). Full-swipe folds the stages into one ballistic, and lift is the default. Lists often have inertia, so a slightly fast sideways stroke crosses the rest point. Rows are tightly spaced, so a diagonal finishes a full-swipe on a neighbor. With no second tap, the system also cannot demand “you tapped this label” before commit. An undo bar can repair, but it appears after commit and the next action may clear it. Full-swipe’s speed is bought by selling the confirmation step.

Studying it

Compare “reveal then tap only” with “full-swipe-to-perform allowed.” Mix tasks: intentional archive, intending only to see buttons, accidental sideways strokes while browsing fast. Dependent measures include surprise-commit rate, later undo use, and time to an intentional archive. Inertia on/off is an independent variable. Split neighbor conditions (dense list vs large cards); dense lists take more full-swipe damage.

Where it stops holding

Reversible, low-risk actions (mark read, pin) make full-swipe less dangerous. A full-swipe still in an offline queue can be withdrawn before sync, delaying the danger. Full-swipe with no undo closes the danger at lift. Game or demo full-swipes are theatrical, not list-productivity context.

Applying it

• Do not enable full-swipe-to-perform by default. If you need the acceleration, enable it only for low-risk commands, and give a strong tracking preview on crossing.
• Offer a short undo after commit, and do not let the next gesture clear it immediately.
• Ask people to “just see what buttons this row has” and to “accidentally swipe sideways while skimming.” The first should not commit. If the second often mutates data in a dense list, full-swipe is too dangerous.

Related

• Same group: C3.17.1 Actions revealed by swiping a row are hidden functions · C3.17.2 Matching swipe distance to the number of actions · C3.17.4 Destructive actions should not be the default full-swipe action
• Adjacent: C3.06 Fling and inertia · C3.33 Gesture undoability
• Search: swipe to commit · perform first action · destructive swipe