Over-aggressive palm rejection swallows intentional finger actions

What it is

A false negative in palm rejection is a palm that becomes ink or a gesture. A false positive is an intentional finger treated as palm, so taps, pinches, and scrolls never happen. In writing, the second cost is high: the other hand wants to zoom a reference, pick a layer, or undo, or the same hand puts the pen down to hit a button, and the swallowed action feels like a dead UI. Stronger is not safer; it is a suppression window larger and longer than the real palm.

Why it happens

Over-rejection stacks. Spatially, the wedge or radius covers a toolbar or a finger target on the canvas. Temporally, the post-leave window is so long that a tap next to the last stroke is still labelled palm. By rule, any large contact is rejected, so a fat fingertip or a two-finger pinch blob crosses the threshold. If a pen-presence prior is read as “ban all touch while the pen is still in the hand (even hovering in air)”, the other hand is dead the whole time. The classifier’s costs are asymmetric: a leaked palm print can be undone; a missed pinch breaks reading or alignment, and people switch to a slower path or decide gestures are broken. Unlike grip-style palm rejection, writing rejection must leave a gap between “pen active” and “two-handed division of labour”: harsh while the nib is down; open as soon as the pen leaves or a clear second hand arrives from the opposite side.

Studying it

Build companion tasks that require fingers: opposite-hand pinch-zoom while holding the pen, undo, sliding a layer panel; and putting the pen down to tap a button next to the last stroke. Sweep suppression radius and the post-leave window.

Independent variables: radius, post-leave duration, whether hover still bans touch, whether the opposite hand is excluded. Dependent measures: intentional-finger failure rate, delay from lift to button fire, whether missed palms rise as suppression relaxes, and “I tapped and nothing happened”.

Successful rejection should cut finger failures without a matching rise in leaked palms, not merely report that palm prints vanished.

Where it stops holding

A pen-only UI (no finger-reachable controls) pays little for over-rejection; the cost appears as soon as touch shortcuts exist. If an accessibility switch is a large finger target, over-rejection blocks the only path. Children’s fingers are large relative to the palm, so area rules kill more often. Fixing “too strong” by turning rejection off only swaps the error type back.

Applying it

• Suppress palm-side touch while the nib is writing; lift it after a short window once the pen hovers or leaves, and admit opposite-side, fingertip-sized contacts.
• Keep undo, zoom, and layers out of the palm wedge; admit opposite-hand pinch.
• Offer rejection strength, not only on/off, and make “tapped, no response” explainable in logs as a false reject.
• How to check: mid-sentence, opposite-hand pinch and undo must fire. Tap a button next to the last stroke immediately after lift; it should fire inside a stated short window. Then check whether palm prints flood back when suppression is relaxed—if they flood more than fingers recover, keep rejection and move the controls rather than grow the radius.

Related

• Same group: C5.04.1 Palm contact is inevitable while writing · C5.04.2 Rejection uses pen prior or contact area · C5.04.3 Rejection direction follows handedness
• Adjacent: C5.07 Division of Labor Between Pen and Finger · C2.09 Accidental Touch and Palm Rejection
• Search: false reject · palm over-suppression · bimanual stylus