The division of labor must stay consistent, or people have to probe every time
Aliases: mapping consistency · mode guessing · probe the tool
What it is
Once what the pen does and what the finger does changes across apps—or even across views in one app—people cannot form a habit. Every contact starts with a probe: is the finger drawing or dragging this time? Does a pen tap on a button count? The contract’s value is predictability, not whether a given mapping is “more reasonable”. Inconsistency hurts more than a wrong default: a wrong default can be learned; a jumping mapping can only be guessed.
Why it happens
Dispatch rules are an implicit mode. A few successful outcomes compile into an expectation: “a finger on the canvas will not leave ink”. When notes keep that rule, photo markup lets the finger paint, and a PDF reader lets the pen scroll, the expectation is slapped each time. The next contact is preceded by a trial: a light tap to see what happens, then the real stroke. The trial is extra work and may already have left unwanted ink or turned a page. If a global setting is overridden by an app without being declared, probing becomes a long-term cross-app behaviour. A hand/pen icon on the toolbar that coexists with device dispatch can state two truths at once: the icon says hand, the pen still inks. Consistency means one dispatch table for a product family; exceptions must be visible on the spot (a canvas chrome when “finger paint” is on), not only in a first-launch sheet.
Studying it
Have people use three views or apps with different mappings in a row, on the same “write a line then zoom” task. Log the outcome of the first contact in each new view, probe counts, and the rule they can state.
Independent variables: mapping consistent across views, exceptions visibly marked, global setting locally overridden. Dependent measures: first-contact errors, exploratory light taps, time to state the current rule, “I have to try first”.
Do not measure satisfaction only under one app’s default mapping.
Where it stops holding
A dedicated finger-paint mode in a drawing tool is a fair exception, but entry and exit must be more visible than the default contract. When OS-level and app-level dispatch conflict, people blame the app while the doc says “follow the system”—both sides must show the same table. A temporary remap on a demo unit that is not restored contaminates every later test.
Applying it
- Write a dispatch table (pen-on-canvas / pen-on-UI / finger-on-canvas / finger-on-UI) and keep it in every view. When breaking it, use a persistent mode chrome, not a one-shot banner.
- When an app overrides a global setting, say “this app differs from the system” inside the app.
- Do not let a toolbar mode and device dispatch assert opposite things.
- How to check: notes → markup → reading, first contact following the original contract; see whether it fails. In one view, let the finger paint with no mark; probes should rise. Restore the mark; probes should fall.