Swipe action

Problem Context

• The surface contains repeated list, feed, card, notification, message, task, file, or table rows with row-scoped actions.
• The same row may support tap-to-open, selection, action menu, drag, vertical scrolling, pull-to-refresh, nested horizontal content, or bulk actions.
• Actions can be safe, reversible, positive, destructive, permission-limited, disabled, or unavailable while the object is syncing.
• Users may interact through touch, mouse, trackpad, keyboard, switch control, screen reader, stylus, or assistive pointer devices.

Selection Rules

• Choose swipe action when the design problem is a horizontal item-level gesture that reveals or commits row-scoped commands.
• Use touch gesture when the question is the broader gesture vocabulary, threshold, feedback, cancellation, target sizing, and equivalent controls across many gestures.
• Use list view when the main problem is row anatomy, scanning, selection, sorting, filtering, pagination, or opening objects.
• Use action menu when commands should be explicitly listed from a visible trigger instead of hidden behind horizontal movement.
• Use undo when the core design problem is post-action recovery after a completed reversible action.
• Use confirmation dialog when a destructive or high-impact row action cannot be safely undone.
• Use pull to refresh for a vertical top-of-scroll refresh gesture, not for horizontal item actions.
• Use drag and drop when the gesture moves an object from a source to a destination rather than revealing row commands.
• Reveal destructive actions before committing them unless the outcome is routine, clearly labeled, and reliably recoverable.
• Do not place hidden swipe action as the only path to primary, critical, security, payment, consent, or account actions.

Required States

• Idle row state with visible row identity and discoverable action path.
• Gesture hint state for teaching that the row supports a horizontal swipe action.
• Partial reveal state showing action label, icon, direction, and affected row.
• Below-threshold snap-back state that leaves the row unchanged.
• Threshold reached state with release-to-commit or release-to-reveal feedback.
• Revealed actions state with tappable row-scoped commands and cancel behavior.
• Committed safe action state with status message and stable focus or row position.
• Destructive action state with undo, confirmation, or review according to reversibility.
• Multiple action or bidirectional state that clearly separates left and right swipe outcomes.
• Disabled or permission-limited action state with explanation.
• Conflict state for vertical scroll, pull-to-refresh, row navigation, selection, nested carousel, or system back gesture.
• Keyboard, screen reader, switch, mouse, and action-menu equivalent state.
• Bulk-selection state where row swipe does not conflict with selected-set actions.
• Mobile compact, large text, and landscape states with readable labels and targets.

Interaction Contract

• Swipe action starts only from the intended row and horizontal axis; vertical scroll and pull-to-refresh win when movement is primarily vertical.
• The row shows a visible background, label, icon, and progress before any command is committed.
• Releasing before threshold snaps the row back and leaves the model unchanged.
• Crossing threshold either reveals actions for explicit tap or commits one clearly labeled action according to the product's risk rule.
• Destructive or high-impact actions are reversible with undo or require confirmation before final execution.
• Every swipe action has an equivalent visible button, action menu item, keyboard command, or contextual action path with the same disabled, pending, success, and recovery states.
• Only one row remains actively swiped open unless the product deliberately supports multiple open rows.
• Completed actions announce the row name, action name, and recovery path where applicable.

Implementation Checklist

• Inventory each row action, direction, threshold, reveal width, commit rule, reversibility, disabled reason, and equivalent non-gesture control.
• Define whether each swipe reveals action buttons, commits on release, or requires a tap after reveal.
• Write direction-specific labels such as Archive message, Mark read, Pin task, or Delete file instead of relying on color or icons alone.
• Set movement thresholds, angle locks, velocity handling, snap-back animation, and system edge-reservation rules.
• Resolve conflicts with vertical scroll, pull-to-refresh, horizontal carousels, row selection, drag handles, nested scrollers, and browser or OS back gestures.
• Make row action menus, visible buttons, keyboard shortcuts, or context menus trigger the same command handlers as swipe.
• Add undo, confirmation, or delayed finalization for destructive actions according to reversibility and external side effects.
• Test accidental diagonal movement, one-handed use, large text, screen reader, keyboard, switch control, mouse drag, trackpad swipe, pointer cancellation, and bulk selection.

Common Generated-UI Mistakes

• Making a hidden swipe the only way to archive, delete, complete, or reveal row actions.
• Committing a destructive action before users see the label or cross a clear threshold.
• Letting vertical scroll, pull-to-refresh, row navigation, and swipe action trigger at the same time.
• Using unlabeled icon-only action backgrounds or color-only destructive cues.
• Offering different commands in swipe and the visible action menu.
• Leaving multiple rows half-open and visually confusing list state.
• Providing no undo, confirmation, or recovery for a risky swipe result.
• Assuming desktop hover hints teach mobile users the gesture.

Critique Questions

• What exact row action does each swipe direction reveal or commit?
• How does the user learn that the row supports swipe action before they need it?
• What threshold, release boundary, and snap-back behavior prevent accidental activation?
• Where is the non-gesture equivalent for keyboard, screen reader, switch, mouse, and assistive pointer users?
• Which outcomes are reversible with undo, and which require confirmation before execution?
• How do vertical scroll, pull-to-refresh, row open, row selection, drag, and system back gestures avoid fighting each other?
• What status message names the affected row and result after activation?