A missing pressed state causes repeated clicks

What it is

The pressed (active) state is evidence, while a finger or pointer is still down, that contact was sampled. It does not report that the task finished; it reports that this press was taken. Without it, there is no receipt belonging to this action before release, and the usual compensation is to click again. The second click is not impatience. It is a rational repair after the causal chain broke on the trigger.

Why it happens

The window in which “I pressed, so it should react now” feels true is short. Pressed sits between contact and release and fills that window: an offset, a darkening, a ripple welds the action to the control for a moment. If the next frame still looks at rest, perception treats the contact as a miss—especially on touch, where the finger hides the control and even a one-frame change is invisible. The repair for a miss is a second press. If the network is even slightly slow, that second press can leave before the first request is locked, producing a double submit, a double order, a double send. Pressed guards the empty interval before loading appears; a loading lock guards a later interval. Both can create extra clicks; the gaps are different.

Studying it

On the same click task, manipulate pressed: present or absent, and whether a finger model occludes it. Log the interval from first contact to second contact, and whether two requests go out.

Independent variables: presence of pressed, delay before it appears, occlusion of the target, time until a loading state appears. Dependent variables: second-click rate, inter-click interval, verbal reports of “I thought it didn’t take.”

A pressed appearance that only starts after release is not a pressed state—it is already result feedback. Time “change during hold” separately from “change after release.” Apply a fingertip occluder on touch; it is unnecessary on mouse.

Where it stops holding

Physical keys supply travel and haptics, so a missing on-screen pressed state can be backfilled by hardware. Soft keyboards and pure touch have no such fallback. Burst fire in a game is a feature: design it as hold-to-repeat and show that repeating is happening. If the system fires the request on pointerdown, there may still be only one request without a pressed state—but people will not know, and they will click again, turning the problem into “two requests plus confusion.” Switch access activates by dwell and has no “during press”; it needs a different in-progress cue.

Applying it

• Switch to the pressed appearance on pointerdown / touchstart, not on mouseup and not when the server answers.
• On touch, put the pressed change outside the fingertip (an outer glow, a whole-control offset) so it does not happen where it cannot be seen.
• Do not let loading stand in for pressed: loading may arrive tens to hundreds of milliseconds later; pressed must be on the contact frame.
• Verify on device with rapid contacts on a submit control, against the request log. If the first contact leaves the look unchanged and a second request appears at a short interval, the missing pressed state is manufacturing the extra click.

Related

• Within the group: E1.02.1 Default, hover, pressed, disabled, and loading states all have to exist · E1.02.2 Visual difference between states must exceed noise
• Adjacent: D1.01 Immediate operation feedback · D1.06 Pressed state · E1.09 Loading buttons
• Search terms: pressed state · active state · repeated click