A finger occludes the operation point and the area below it
Aliases: finger occlusion · touch visibility · operation point
What it is
During touch, a finger occludes the operation point and the area below it, preventing direct view of the exact landing point, object edge, or local feedback. Occlusion is an inherent visual–motor constraint of direct touch, especially for small targets, text insertion, map markers, and canvas detail.
Why it happens
People plan from a visible target before press, then finger and palm cover screen area while held. Contact lies under the finger rather than its visible edge, so confirmation is delayed or absent. There is an easily overlooked time structure here: occlusion duration is, in essence, equal to the gesture's own duration. In a quick tap, the finger lands and lifts almost immediately, so the occlusion window barely overlaps the confirmation feedback that appears after lift — people can see the result the instant they lift their finger. A held drag or long-press edit is different: occlusion begins at contact and fully coincides with the exact decision window in which someone needs to see the current state to decide what to do next, with the finger sitting the entire time on the very area that needs to be seen. At that point occlusion is not "a brief moment of not seeing" — it is "the entire decision process happening blind."
Studying it
Across fingers, grips, target positions, and tasks, observe occluded area, confirmation time, errors, and retries. Compare taps, held drags, and precision edits because their occlusion duration and feedback need differ. Concretely, plot the occlusion window and the visual-decision window on the same timeline for each gesture and measure their overlap ratio — a quick tap's overlap should be near zero, while a held drag's overlap is often near 100%, and this ratio alone predicts whether the gesture needs extra feedback placed outside the occlusion area.
Where it stops holding
Occlusion does not make touch unusable: large targets, low-risk actions, and quick lift can tolerate it, precisely because the occlusion window and the decision window do not overlap to begin with. The issue is fine work requiring sustained visual confirmation; rearrange feedback and selection rather than merely shrinking icons or raising resolution.
Applying it
- Keep critical confirmation, insertion points, and small handles out of the finger's likely path.
- Offer offset cursors, magnification, or held previews for fine tasks, prioritizing gestures with a high overlap between the occlusion window and the decision window (held drags, long-press edits).
- How to check: plot the occlusion window and the visual-decision window on a timeline for each gesture and compute their overlap ratio; gestures with high overlap need feedback placed outside occlusion first, while ones with low overlap can be left as is.