The same device can switch between two input methods

What it is

A 2-in-1 folds flat as a tablet, then opens back onto a keyboard. In one editing session a finger hits the toolbar; a moment later the trackpad hits the same button. Input modality switching is that back-and-forth on one desktop-class device—not a split of labor across two machines, and not a pen-versus-finger contract on a tablet. The switch often has no toggle and no banner. A hand simply leaves the keys and lands on glass. This entry is only the fact that both inputs occur on the same device. It is not about how large a target must be, and not about what the interface must change at the instant of the switch.

Why it happens

Keyboard and mouse shrink the point of action to a pixel-level cursor; the hand can stay off the screen. Touch turns that point into a finger pad; the hand must occupy pixels. The two inputs demand different posture, precision, and preview-before-commit. Convertible hardware stacks both on one chassis: typing in the lap, tenting for a demo, lying back to mark up. The channel follows posture, not the app process. The OS may never fire a session-wide “now we are in touch mode”; many systems only stamp pointerType on each event. An app that probes “is there a mouse?” at launch and freezes its interaction assumptions will fail in the second half of the task. People do not treat “I started using a finger” as an event that should require relaunching software.

Studying it

Run mid-task input switches on convertible hardware, rather than only a mouse-only group and a touch-only group. Have people finish a stretch with keyboard and mouse, then fold the device into tent or tablet and continue in the same UI.

Independent variables: starting input, whether a mid-task switch is required, posture (clamshell / tent / tablet), whether the app locks an input hypothesis at launch. Dependent variables: time to first successful action after the switch, misses and air taps, whether people hunt for a tablet-mode setting, whether the product now “feels like a different computer.”

Labs often park an external mouse on the desk, so the touch path is never walked. Real switching shows up in pointer-type sequences in event logs, or in field observation of folding, not in a survey item about “I mostly use a mouse.” Do not treat pen-versus-finger experiments on tablets as evidence for this claim—that is a different channel contract.

Where it stops holding

Tower desktops with no touch layer, and workstations used only with keyboard and mouse, do not switch. A touch-only all-in-one that never sees a pointing device does not switch either. An external display on a touch laptop often takes the mouse while touch stays on the laptop panel—two inputs on two surfaces, not a back-and-forth on one. Experts may spend a whole task on one input; switch rate approaches zero, and the issue shrinks to occasional demos or reading in bed.

Applying it

• Identify pointer type per event; do not freeze the session’s interaction model from a launch-time “has a touchscreen” check.
• Keep both the keyboard-mouse path and the touch path completable; do not require a system tablet mode before anything can be tapped.
• Do not require relaunch, a new window, or an account switch to finish an input change.
• Verify: in one window, complete the main path with the mouse only, then close the keyboard or tent the device and repeat the critical actions with a finger. Any step that forces a trip to Settings or a relaunch means input was treated as a boot-time device property.

Related

• Within the group: K2.07.2 Hit targets must follow touch size, not mouse size · K2.07.3 Switching input methods needs immediate adaptation
• Adjacent: K2.06 Design Freedom from Hover · K3.04 External Keyboard Mode · C1.06 Hover and its absence on touch
• Search terms: input modality switching · hybrid device · convertible PC