Mouse, keyboard, and touch must be accommodated together
Aliases: 2-in-1 · pointer type · press and hold · touch target
What it is
A Windows window often receives keyboard, mouse, and touch in the same session: a laptop folded into a tablet, a touch display next to a mouse, a trackpad and a finger a few seconds apart. Concurrency does not mean two apps, and it does not mean choosing a mode at launch. It means one UI that changes hit area, the right-click equivalent, and its dependence on hover according to the current pointer type. A mouse brings precise clicks, a right button, and tooltips; touch brings a thick finger, no hover, and press-and-hold for the context menu.
This is about both pointers being able to come down now, not about also supporting pen and gamepad. Shipping a separate large-button layout for touch, and making the mouse user switch into “desktop mode,” treats concurrency as a product-line problem. Windows treats it as a runtime fact of the window.
Why it happens
The system tells the window whether the last pointer was mouse or touch. Hit targets, scroll inertia, and how a context menu opens should follow that signal, not a device SKU—the same 2-in-1 is a mouse machine on its keyboard base and a touch machine when the base comes off, and the window never restarted. Right-click and press-and-hold are two doors into one command: right-click only, and touch users cannot open the menu; press-and-hold only, and mouse users feel the UI is late. Hover tips never appear under a finger, so they cannot be the only explanation.
Drag and scroll use different thresholds per pointer. A mouse drag can select text or grab a scrollbar thumb; a finger swipe is, by default, panning. Handing mouse “press-to-select” to touch makes a list unscrollable; handing the touch pan threshold to the mouse makes text unselectable. Concurrency means both recognizers are registered and dispatched by pointer type, not averaged into one uncomfortable threshold.
Where it stops holding
A mouse-only desktop (tower, no touch digitizer) need not size every target for a finger, but the moment the product claims a touch display, the minimum target follows touch. A touch-first tablet that suddenly has a Bluetooth keyboard must honor focus and shortcuts immediately; the keyboard is not “a peripheral we will handle later.” Pen and gamepad are other pointer classes, with different hit and hover rules; “we already did touch” does not cover them. In remote desktop and virtual machines the reported pointer type can be wrong; degrade from observed misses, not from the flag. Fullscreen games that take exclusive input swallow pointer messages; concurrency resumes after exclusive mode ends.
Applying it
- Size hit areas from the current pointer type: enlarge tappable controls under touch, allow denser toolbars under a mouse, and do not ship two pages.
- Offer context menus from both right-click and press-and-hold. Anything explained only in a hover tip needs a persistent or tappable door for touch.
- Dispatch text selection, list scrolling, and drag-and-drop by pointer type; do not use one press threshold for both inputs.
- Verify on a 2-in-1 or a touch window: complete right-click, hover, and precise drag-select with a mouse, then—without restarting—complete press-and-hold menus, scrolling, and primary buttons with a finger. Any step that needs a restart, a “mode” switch, or that is hittable by mouse but not by touch means concurrency was shipped as two products. Then attach a keyboard and confirm Tab focus and shortcuts work at once.