Shortcut conflicts need a customizable way out
Aliases: keybinding customization · shortcut collision · rebinding
What it is
Two in-app commands, or an in-app command and a user-installed extension, input method, or another always-on tool, will want the same chord. Customizable resolution means the collision is made visible and someone can rebind one side—not a silent loss for the latecomer, and not the factory binding winning forever.
System chords are not in this set; those cannot become app commands. This is the way out after an application-layer crash.
Why it happens
Desktop command sets are large and the chord space of “modifier × letter” is not, so collisions are the default. Plug-ins, browser extensions, and input methods each register another batch, and the conflict stops being “two features happen to share a name” and becomes “the same keys pointed at different work in different months.” People remember a hand shape. When that shape suddenly does something else, the expert path becomes a random path.
A factory binding that always wins ignores the set someone already rehearsed (from the last editor, the last machine). A latecomer that fails silently is a chord printed on a menu that does nothing. Customization turns runtime grabbing into a visible table: which two commands want the same keys, who holds them now, what to change them to. Grossman and colleagues’ hotkey work shows shortcuts are learned by repetition and visible labels; a conflict breaks that already-learned loop, so the way out has to be rebinding, not another paragraph of “please remember the new keys.”
Studying it
Give skilled users a set of bindings they already know, then introduce a conflict (a new feature or a plug-in taking the same chord). Compare “cannot rebind,” “can rebind but the conflict is not flagged,” and “conflict flagged and rebindable.” McGrenere and colleagues’ evaluations of customizable interfaces show experts need to be able to change things, but the entrance to change cannot be harder to find than the conflict itself.
Independent variables: whether the conflict is flagged, whether rebinding is allowed, whether the entrance lives in settings or at the moment the conflicting keys are pressed. Dependent variables: times the conflict is noticed, rate of successful rebinding, trials until the old hand shape maps to the intended remaining command, accidental invocations.
Running shortcuts in an empty test account measures the conflict away—real desks already have an input method and a pile of always-on tools.
Where it stops holding
A tiny command set (a handful of keys on a calculator) can be disambiguated once at the factory; it does not need a full shortcut editor. A touch-first desktop app that almost nobody drives from the keyboard is too small a surface to justify a conflict editor. Rebinding must not open onto system chords, or “customizable” dismantles window management. On a shared machine, rebindings follow the account, not the hardware.
Applying it
- List every binding in shortcut settings; show two rows that share a chord in a conflict state; allow either side to change, and check for a new collision before save.
- When already-conflicting keys are pressed, do not silently pick a winner: show which two commands are fighting, and offer “rebind now.”
- Verify by binding Save and a plug-in command to the same chord; settings should show the conflict. After a rebind, the old hand shape fires only the side that kept the chord. Then sample the ten most-used keys on a real desk with an input method installed, and see whether an outer tool ate any of them with no notice.