A swipe-triggered action should be undoable by a reverse swipe

What it is

A swipe commits at lift. There is no press-state “slide off to cancel.” When someone flips the wrong page or sends a card away, the cheapest motor repair is another swipe the other way. If the forward swipe can do something the reverse cannot, or the reverse does something unrelated, the gesture becomes a one-way gate. This is reversibility at the command layer, not delete-confirm after a list row reveals buttons.

Why it happens

Ballistic repair is symmetry: muscle memory holds the last direction, and reversing it is cheap. Pagers, story streams, and card stacks put state on an axis; forward and back are one step on that axis. If forward is “next” and reverse is stolen for “close the whole module” or “open a drawer,” symmetry breaks and repair has to hunt for a button. Swipes are also fast; a misfire is barely previewable before lift. Reversibility is what turns an early commit from a disaster into a round trip. Irreversible outcomes (pay, send, hard delete) should not be bound to a swipe at all—that is a severity question—and a reverse swipe cannot resurrect them; they need an undo stack.

Studying it

Build a paging task that invites mis-flips, and compare “reverse swipe returns” with “only the top-left back control.” Dependent measures include repair time, how long the error stays on screen, and whether people even try reverse. Add a condition where reverse maps to an unrelated command, and measure collateral damage. Eye tracking adds little; the second gesture’s direction in the 500 ms after lift is the signal. Field logs full of forward-then-reverse pairs mean people already treat symmetry as the undo protocol.

Where it stops holding

A one-way flow (archive left, complete upward) has no natural reverse. Offer an explicit undo bar rather than inventing a reverse command nobody will know. A carousel that wraps last-to-first makes reverse no longer “undo that last step” but “travel the other way around the ring.” A swipe with a load side effect (already marked read on a server) can reverse only the local view; server state needs its own undo API.

Applying it

• Keep swipe state on one axis: next/previous page, next/previous story. Pair them. During the slide, reveal the neighbor so direction can still change before lift.
• Do not sell the reverse slot to an unrelated feature; unrelated features get buttons. Do not commit irreversible work on a swipe.
• Ask people to flip three pages quickly and “go back to the one just now,” hands only. If they hunt for a button or reverse-open a drawer, symmetry never formed. In logs, treat forward–reverse pairs closer than a second as repairs.

Related

• Same group: C3.05.1 A swipe is jointly classified by direction, distance, and velocity · C3.05.2 Angular tolerance on a swipe sets the misclassification rate · C3.05.4 A swipe leaves no trace and needs a visual hint that it exists
• Adjacent: C3.14 Back gestures · C3.33 Gesture undoability
• Search: swipe undo · reverse gesture · pager symmetry