Switching input methods needs immediate adaptation

What it is

Someone tents a laptop and the first finger is already on the toolbar. Runtime input-mode adaptation means the interface changes hit testing, scrolling, and what still depends on hover at that instant—not after a relaunch, not after opening a new window, and not after the person finds a system “tablet mode” switch. That the same device will change input is the premise. This entry is only that adaptation has to happen at the moment of the switch, not at the next cold start.

Why it happens

Input switches on a scale of seconds, not sessions. Between leaving the keys and the finger pad hitting glass there is often no tappable “switch” step. OS tablet mode turns adaptation into a session flip: on, the whole machine is touch; off, the whole machine is keyboard and mouse. Real use interleaves both in the same minute. A session flip leaves people either touching mouse-density chrome or driving a pointer across touch-density chrome, and the flip itself has to be found. Per-event adaptation uses the current pointer type for this hit and this feedback: a finger down should pan content directly and expose a tappable stand-in for hover-only secondary actions; when the cursor returns, those stand-ins need not block the expert path. If adaptation lags until after a layout pass, the first hit has already landed on hotspots from the previous input hypothesis.

Studying it

Compare three strategies: lock at launch, flip with system tablet mode, adapt per pointer event. Change posture mid-task and watch the first hit and the next few.

Independent variables: adaptation grain (process lifetime / system mode / per event), whether layout finishes reflow before the first hit, whether hover-only controls have a touch stand-in. Dependent variables: first-hit success after the switch, misses caused by layout jump, time to find the system-mode switch, instability when switching back and forth.

Layout jump itself creates new errors: a button moves after the finger is down. Code “no adaptation” separately from “adaptation too late, first hit on the old position.” A lab that says “turn on tablet mode, then start the task” never sees the real first-hit problem.

Where it stops holding

When a whole task uses one input, immediate adaptation has no observation window and will not be felt. If adaptation changes decoration but not hit testing and discoverable paths, the first hit still fails. Drag the window onto a non-touch external display and tap the laptop panel—two surfaces can keep two inputs for a long time; cutting on “the screen that holds the focused window” cuts the wrong one. Games and full-screen talks that treat any reflow as a break in immersion are safer sharing one already-touch-sized hit set than oscillating density.

Applying it

• Branch on pointer events, not on a tablet-mode toggle; the first touch should already be treated as a touch hit.
• Hover-only actions need an immediately tappable stand-in under touch; do not wait for someone to notice there is no cursor.
• When layout grows from mouse density to touch density, do not move a target after the finger is already down; chrome that can live at touch size should stay at touch size.
• Verify: with the window open and the mouse still in use, tent the lid and immediately tap the same cluster the mouse was on. The first hit must match intent. Fold back to the mouse and confirm pointer precision does not require relaunching. Log “first hit missed” separately from “the button moved during the first hit.”

Related

• Within the group: K2.07.1 The same device can switch between two input methods · K2.07.2 Hit targets must follow touch size, not mouse size
• Adjacent: K2.06 Design Freedom from Hover · C1.06 Hover and its absence on touch · K3.04 External Keyboard Mode
• Search terms: runtime input adaptation · pointerType · tablet mode