Touch gesture

Problem Context

• The interface supports touch input on phones, tablets, kiosks, touch laptops, drawing surfaces, maps, media viewers, carousels, boards, canvases, or spatial controllers.
• The same feature may also be used with mouse, stylus, keyboard, switch control, screen reader touch exploration, head pointer, or assistive pointer devices.
• Gestures can be basic single-pointer actions such as tap and drag, or more demanding path-based and multipoint actions such as swipe, pinch, spread, rotate, two-finger tap, and edge gestures.
• Gesture conflicts often occur between scrolling, panning, selection, reordering, dismissal, navigation, refresh, zoom, drawing, and destructive actions.

Selection Rules

• Choose touch gesture when the design question is the recognition, feedback, fallback, and cancellation behavior of touch input itself.
• Use swipe action when the pattern is specifically a horizontal or directional item action such as archive, delete, complete, or reveal action buttons.
• Use pull to refresh when the vertical drag from scroll top refreshes content.
• Use long press when sustained contact reveals context menus, selection, preview, or drag pickup.
• Use drag and drop when the core task is moving an object from a source to a destination.
• Use bottom sheet when the gesture changes a detented bottom overlay; document the sheet-specific scroll-versus-drag priority there.
• Use carousel, map view, data visualization, or calendar view when the primary pattern is the content surface and gestures are only one input method inside it.
• Provide simple single-pointer controls for any function that otherwise requires a multipoint or path-based gesture unless the gesture is essential to the task.
• Do not hide critical, destructive, security, payment, consent, or account actions behind an undiscoverable gesture-only shortcut.

Required States

• Idle state with visible touch targets, gesture hints when needed, and no reliance on hover.
• Touch down or gesture start state that identifies the active target.
• Move or preview state showing direction, distance, scale, rotation, selected object, or next outcome.
• Threshold-not-met cancellation state that snaps back or leaves content unchanged.
• Commit state after the gesture passes a clear threshold or release boundary.
• Conflict state where scroll, pan, drag, swipe, refresh, or edge navigation wins predictably.
• Single-pointer alternative state for multipoint or path-based functions.
• Equivalent button or menu state for users who cannot or do not discover the gesture.
• Target-size and spacing state for compact controls.
• Disabled, unavailable, or system-reserved gesture state with explanation.
• Undo, reset, or recovery state for reversible gesture outcomes.
• Mobile compact, large-text, landscape, stylus, and assistive-touch states.

Interaction Contract

• The gesture starts only from the intended target or gesture region, not from unrelated content.
• Movement thresholds, velocity thresholds, direction locks, and edge zones are defined before implementation.
• Feedback begins early enough for users to know whether they are scrolling, panning, dragging, swiping, zooming, rotating, selecting, or dismissing.
• Users can cancel before the commit boundary by reversing, releasing outside, pressing cancel, or using a visible reset where the platform supports it.
• Multipoint or path-based gestures have simple single-pointer alternatives such as buttons, handles, steppers, menus, or tap targets.
• Gesture shortcuts do not replace keyboard, screen reader, switch, pointer, mouse, stylus, or assistive-device operation.
• Targets meet minimum size or spacing expectations, or equivalent controls are available on the same page.
• System gestures, browser gestures, assistive-technology gestures, and platform navigation gestures are not overridden unless the platform explicitly supports the custom behavior.

Implementation Checklist

• Inventory every touch gesture, target region, affected object, outcome, threshold, pointer count, direction, speed, and commit boundary.
• Define whether each gesture is basic, path-based, multipoint, dragging, system-reserved, or content-specific.
• Add visible controls for zoom, reset, previous, next, move, dismiss, select, refresh, rotate, or recover when the gesture is not enough.
• Set target size and spacing for touch controls and avoid placing dangerous actions near routine scroll or navigation targets.
• Provide live feedback for start, movement, invalid direction, threshold reached, cancellation, commit, undo, and failure.
• Resolve conflicts between vertical scroll, horizontal swipe, nested panning, drag handles, pull-to-refresh, browser back, and screen-reader touch exploration.
• Test one-handed use, thumb reach, tremor, slow movement, accidental diagonal movement, multi-touch failure, stylus, mouse, keyboard, screen reader, zoom, large text, and landscape.
• Record analytics for failed gesture attempts only in aggregate and without logging sensitive path or content data.

Common Generated-UI Mistakes

• Requiring pinch, rotate, two-finger swipe, or shape gestures with no single-pointer alternative.
• Making a hidden gesture the only way to find navigation, delete, refresh, zoom, or edit controls.
• Letting short diagonal scroll movements trigger swipe actions.
• Using tiny targets or placing opposing actions too close together.
• Overriding operating-system, browser, or assistive-technology gestures.
• Committing actions on touch down instead of release or a clear threshold.
• Providing no cancel, undo, reset, or recovery for high-friction gesture mistakes.
• Assuming desktop hover hints will teach mobile users a gesture.

Critique Questions

• Which exact function depends on touch, path, velocity, pointer count, or contact duration?
• What visible control performs the same function for users who cannot do the gesture?
• How do users know when the gesture has started, crossed threshold, canceled, or committed?
• What prevents scroll, pan, swipe, pull-to-refresh, drag, and system back gestures from fighting each other?
• Are targets large enough and spaced far enough to prevent accidental activation?
• What happens for screen reader touch exploration, switch control, head pointer, stylus, mouse, keyboard, large text, and landscape?
• Is this better handled as a named pattern such as swipe action, pull to refresh, long press, drag and drop, bottom sheet, or carousel?