Barrel-button assignments differ by app and lack a shared cross-app convention

What it is

The same side button may be a context menu on the system desktop, an eraser in notes, an eyedropper in a drawing app, and next-page in a reader. People cannot form “this key always does X”, and every app entry starts with a probe or a trip to settings. What is missing is a cross-app convention layer, not one app using the key wrongly.

Why it happens

The OS usually exposes pen buttons as bindable input, with a weak default (or only the desktop metaphor “second button = right click”), and apps then override. Overrides are often undeclared, and the key’s behaviour may still change with the current tool—eraser while a brush is selected, duplicate while an object is selected. Uncertainty is then triple: across apps, across tools, across OS versions. Unlike keyboard shortcuts, pen keys have no widely printed cheat sheet, and rarely show what they will do at the moment of press. People probe: press, see, undo if wrong. Probing is unacceptable on destructive bindings. If the system offers a global pen-key panel and the app silently swallows the event, people edit a setting that does nothing, and trust breaks further.

Studying it

Have people use three or four apps that declare different side-button bindings, on expected actions such as erase / menu / undo. Log the first press’s outcome, whether they open settings, and the rule they can state.

Independent variables: binding close to the system default, prompt of the current binding on entry, whether the system can lock the binding. Dependent measures: first-press errors, settings openings, correctness of the stated rule, “I have to try every time”.

Report in-app consistency and cross-app consistency separately.

Where it stops holding

A professional app may bind the key to a domain verb (eyedropper, temporary hand) but should inherit a system-level “primary side button” default and declare the override. A closed device with one app (a signing pad) has no cross-app problem. Web apps reach pen buttons inconsistently, so convention is harder and the page should show the current binding.

Applying it

• Follow the system default when possible. On override, a non-modal first-use hint should read “in this app the side button = …”, with a setting to revert to system.
• Do not silently change the side button with the current tool; if it must change, keep state on the cursor or beside the key.
• Do not bind destructive actions as silent side-button defaults.
• How to check: desktop → notes → drawing, same habitual press on the side button, log failures. After an override hint, first-press errors should fall. Change the binding in system settings and confirm the app does not swallow it.

Related

• Same group: C5.10.1 Barrel buttons map to tool switch or menu · C5.10.2 The eraser end is recognised by flipping the pen · C5.10.3 Button placement must miss the natural finger rest
• Adjacent: C5.07 Division of Labor Between Pen and Finger · C5.09 Pressure Curves and Individual Fitting
• Search: button binding · stylus convention · cross-app shortcuts