Actions revealed by swiping a row are hidden functions

What it is

Sliding a list row aside reveals delete, archive, more. Those commands are invisible on the resting row. Swipe actions are therefore hidden functions: fast for people who know, invisible to people who see only primary content and assume there is no second action. They accelerate regulars. They cannot be the only entrance.

Why it happens

The row’s front is spent on title, subtitle, avatar; there is no room for three more buttons, so the buttons hide in a horizontal displacement. Discovery rides on convention (mail and to-do have trained some people) or a one-time peek. Industry lists (invoices, charts, devices) without that convention cannot borrow the memory. Swipe also fights horizontal scroll and back, so novices are even less willing to try. Hiddenness becomes non-access under assistive tech: screen-reader users typically cannot see “this row swipes” unless the same commands appear in an accessible action menu.

Studying it

With no briefing, ask people to archive a named row. Log who swipes first, who opens detail, who long-presses. Retest the next day. Control: a resting “more” ellipsis on the row. Recruit industry users separately from heavy mail users. Self-report of “I know you can swipe” overestimates actual attempts.

Where it stops holding

On strongly conventional lists (system mail, reminders) hiddenness is lower, though some people still miss the convention. Desktop puts the same commands on a right-click; touchscreen swipe is a cousin, not proof of substitution. Hiding the primary action (open) behind a swipe as well makes the main path vanish, which is beyond “second actions are hidden.”

Applying it

• Every action the swipe reveals must appear again in the detail, a long-press menu, or a trailing ellipsis.
• For new users, a peek or one instructional swipe on a row beats burying the feature in help.
• Ask someone new to the product to archive a row. If everyone opens detail to find a button, swipe is not an entrance. Time regulars: swipe should be faster, or it is not even an accelerator.

Related

• Same group: C3.17.2 Matching swipe distance to the number of actions · C3.17.3 The danger of a full swipe that executes immediately · C3.17.4 Destructive actions should not be the default full-swipe action
• Adjacent: C3.05 Swipe · C3.20 Gesture discoverability
• Search: swipe actions · leading trailing swipe · hidden command