R4.10.1input-agnostic applicationdesign

The same app must work across mouse, touch, pen, and gamepad

Aliases: multi-input Fluent · input-agnostic · mouse touch pen gamepad

What it is

Fluent defines “one app” as one product that still completes its tasks under mouse, touch, pen, and gamepad — not a build per input. 2-in-1s, desktops, large canvases, and living-room devices with a pad swap input inside a session. People do not accept “this feature is mouse-only.” Call the requirement an input-agnostic application: the task model stays put, the hit model changes with the device.

This is not the minimum coexistence list that mouse and touch must both be tappable — that covers two pointers. Here there are four channels: precise click and hover (mouse), direct contact (touch), ink and pressure (pen), spatial focus movement (gamepad and D-pad). Drop one, and on that class of device the product is no longer the same product.

Why it happens

Windows treats input as a hot-pluggable capability, not a boot-time attribute. The same window takes pen markup one minute and a gamepad on the sofa the next. If a task is written into one hit method — delete that appears only on hover, a menu that appears only on right-click, a target only a precise click can reach — changing input equals losing the function.

Agnosticism is the same task exposing several arrival paths: focus can enter, touch can hit, pen can write, a pad can move. Paths need not be equivalent — pen has pressure, mouse has hover — but the task must not live in only one of them. The default expectation is “the app is still here,” not “please switch back to the keyboard.”

Where it stops holding

Phone-only touch apps are not under this four-channel Fluent demand; they have their own input set. A professional inking tool may make pressure and tilt core, but it still owes the mouse a degraded path that completes the same task, or the product vanishes in a pen-less session. A game that declares pad-only is a different product contract; do not mix it with the productivity demand. A kiosk whose input is bolted to the cabinet does not have the hot-plug assumption.

Applying it

  • For each critical task, write four columns — mouse, touch, pen, gamepad — with the arrival steps. A blank column gets a path that does not depend on that input’s specialty.
  • Commands that appear only on hover also get a persistent entry after selection, or a keyboard / pad equivalent.
  • Pen ink is an enhancement, not the only write path; the same content can be typed or inserted by touch.
  • Verify on a 2-in-1 without restarting the app: complete the same core task with mouse, then touch, then pen, then pad (or arrow keys as a stand-in). Any step that requires “switch back to input X first” means the task was written into a single hit model.

Related

  • Same group: R4.10.2 Light, material, and depth signal interactivity · R4.10.3 Free window size means layout cannot assume a fixed canvas
  • Adjacent: R4.03 Windows platform conventions · K2.07 Touch and mouse coexistence
  • Search terms: input-agnostic application · Fluent · gamepad navigation

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/R4.10.1