Review Keyboard Shortcut Conflicts Before Assigning Keys
As of 2026-10-23 · The AZET team. We wrote this practical exercise for fun and reference. The editor, commands, and shortcut assignments below are invented; they describe a design review, not an available AZET feature.
A fictional sketch editor assigns the letter R to both Rotate and Rename. That looks like a collision until you learn that Rotate belongs to the canvas and Rename belongs to a selected layer. Then a harder question appears: what happens when a layer is selected while the canvas has focus?
A useful shortcut review starts with that question. A list of keys alone cannot explain which action wins. An AI-assisted draft should expose the missing context so the designer can decide it explicitly.
Describe the action before choosing the key
For each command, record its full name, the object it affects, where it can be invoked, and what the user sees afterward. Add a field for whether text entry is active. These fields describe your proposed interface; do not let a generated answer fill them from assumptions about other applications.
In our example, Rotate affects selected canvas objects. Rename affects one layer label. Both commands have visible menu entries. Neither needs an immediate key assignment for the prototype to remain usable.
That last detail creates room to decide carefully. An unassigned shortcut is an honest design state. A familiar letter attached to an ambiguous command can disguise an unresolved interaction.
Build a small collision worksheet
Use a deliberately incomplete map:
| Key | Action | Proposed context | Open question |
|---|---|---|---|
| R | Rotate | Canvas | Does layer selection count? |
| R | Rename | Layer list | Must the list have focus? |
| G | Group | Canvas selection | What happens during text entry? |
| G | Grid preview | Preview panel | Is the panel context exclusive? |
The worksheet contains two kinds of uncertainty. R has overlapping object descriptions. G has a proposed context boundary that has not been tested. Calling every repeated key a defect would miss that distinction.
Ask for a classification of each pair: clearly overlapping under the supplied rules, clearly separate, or unresolved. Require a reason referring to the stated contexts. A model should not decide that a panel automatically owns keyboard focus unless you have specified that behavior.
A prompt that leaves authority with the designer
Review this fictional shortcut worksheet using only the context rules supplied. For each repeated key, identify the commands involved, describe a situation where both might be eligible, and label the result overlapping, separate, or unresolved. Quote the rule that supports the classification. Do not invent keyboard conventions or assign replacement keys. List questions I must answer before the map can be tested.
Review the generated questions against the interface sketch. A useful question might ask whether selecting a layer transfers focus to the layer list. A less useful suggestion might replace R with an elaborate chord without resolving the underlying ambiguity.
Answer the context question first. Then revise the map. If Rename requires explicit focus inside the layer list, state that condition in its row. If focus is invisible, add a design task to make the active context understandable before treating the collision as settled.
Test mnemonic quality separately
Conflict review and mnemonic review serve different purposes. Once eligibility is clear, look at whether a shortcut has a memorable relationship to its action within your chosen vocabulary.
For this exercise, write two candidate letters beside each unassigned action and explain the association in plain language. Keep weak associations visible. Do not present a model's preferred letter as evidence that a user will remember it.
Also inspect collisions between action names. If both “Group” and “Gather” describe the same operation in different parts of your draft, choosing a key may be premature. Agree on the command wording, then return to the assignment.
Rehearse the boundary cases
Create a paper walkthrough with three states: the canvas is active, the layer list is active, and a label is being edited. For each state, ask what pressing R would do under the revised rules.
Record the expected outcome before trying a prototype. Keep observed behavior in a separate column. If no prototype exists, leave that column blank. A predicted outcome is not a successful test.
Include an escape route in the design: a visible command a person can select without remembering the shortcut. Also note any operating-system or browser assignments that still require checking in the actual environment. This article does not supply a universal inventory of reserved keys.
FAQ
Must every repeated key be removed?
No. Your design may intentionally reuse a key in exclusive contexts. The review needs an explicit rule for determining which context applies and a way to inspect that rule in practice.
Should AI choose the final shortcuts?
It can help draft alternatives and reveal contradictions in your worksheet. The final choice still depends on your interface, users, environment, and observed behavior. A generated preference is only a proposal.
What can I finish without building the interface?
You can finish the command inventory, context definitions, unresolved questions, and expected outcomes. Keep runtime verification separate until you have something that can receive real key input.
Following AZET
The E1 maker introduction, dated October 3, 2026, described AZET's assistant and early-access waitlist. That dated source does not establish support for this shortcut exercise or verify current availability.
For the AZET waitlist, visit azet.io and consult the information shown there.