Repeat-trigger intervals trade responsiveness against debounce

What it is

Debounce does not make a button slow. It gives the same target a minimum repeat interval: after the first commit, later hits shorter than that interval are dropped or coalesced. Too short, and bounce leaks through. Too long, and the next intended tap waits. The number is an explicit trade between responsiveness and artifact suppression. It has to be chosen by control risk, not as one magic millisecond for the whole app.

Why it happens

Bounce intervals pile up on the short end; intended second taps centre later; the two distributions overlap. The latch cuts inside that overlap: too far left, bounce leaks; too far right, fast hands are killed. Pay and send have asymmetric cost—an extra commit is worse than tens of milliseconds of wait—so the latch can sit right. A keyboard delete key and a game fire button reverse the cost. The latch can hang on end (closer to “the fire”) or on begin (blocking a second press that has not lifted). If haptics already fired on the first press, a dropped second must not fire them again, or the user will believe the second was accepted. A global interval also blocks tap-A-then-tap-B, so the latch must carry target identity, ideally plus a spatial radius.

Studying it

Plot bounce-interval and intended-repeat histograms and pick the cut that matches acceptable leak and kill rates. Independent variables are control class (submit / toggle / key), haptics on or off, and whether the latch hangs on begin or end. Dependent measures are residual bounce rate, fraction of intended seconds dropped, and a rating of “the button went dull.” Fit fast young hands and slower older hands separately; one cut rarely serves both. Do not set a submit button’s interval from a lab task that says “tap as fast as you can”; that shoves the cut down into the bounce mass.

Where it stops holding

Switch scanning for accessibility and key-repeat on an external keyboard have their own timescales; a touch bounce interval will eat legitimate repeats. Idempotency for a networked button belongs at the transaction layer (an idempotency token); a front-end gap cannot stop a double submit from two ends. If the interval is “wait until the slow animation finishes,” users feel jank, not debounce. Bounce’s physical time does not change with DPI or refresh; writing the interval in frames secretly changes duration between 60 Hz and 120 Hz.

Applying it

• Write intervals by risk: longer for pay/send, shorter for list selection, bound in code to a target id, not a process-wide lock.
• Do not play haptics or press animation for a latched-out second tap, so “it looked like it took, the business did not” cannot happen.
• Watch production interval histograms: if the bounce peak still streams through, move the latch a few milliseconds right; if intended repeats pile up killed just past the latch, split by control class rather than lengthening the whole site.

Related

• Same group: C2.22.1 Bounce clicks are rapid extra triggers from contact rebound, not intent · C2.22.3 Overlong debounce blocks intentional rapid taps · C2.22.4 Mechanical key bounce likewise requires software debounce
• Nearby: C3.01 Tap · C3.25 Long-press duration thresholds and alternatives
• Search terms: debounce · refractory period · repeat interval