Context-menu content changes with the target object
Aliases: context menu · right-click menu · contextual actions
What it is
A context-sensitive menu offers actions related to the object currently pointed at or selected. Files, text, graphic nodes, and blank canvas can show different menus because available actions depend on object type, state, permission, and selection set rather than a fixed screen location.
Why it happens
On invocation, the system resolves the target and current state, then filters, orders, and displays applicable commands. This puts low-frequency, object-specific actions near their point of use, reducing travel to a global toolbar. The cost is that content changes: people must work out which object a command will act on.
Going one layer deeper into what "resolving the target" actually means: it is not a single object but a triple — target type (file / folder / text / shape), target state (read-only / locked / mid-edit), and the current selection set (single / multiple / none). Their combinations mean the same right-click location can pop up a structurally different menu depending on the moment, which is the real difference between a context menu and a fixed menu bar: a menu bar's command set is determined only by application state, while a context menu's set is determined by "application state × current object" jointly — one extra dimension. A menu designer must define, for every cell of that combination space, what should appear there, rather than designing one generic list and greying out inapplicable items. Greying-out is the most common cause of garbled commands under mixed-type or multi-selection.
Studying it
Across object types, selection counts, permission states, and blank areas, test command discovery, wrong-target actions, time, and menu dismissal. Observe whether people had selected the correct target before opening the menu and whether it communicates its actual scope. An easily overlooked variable is mixed selection — a file and a folder selected together, or a mix of editable and read-only objects — where whether the menu should show the intersection or the union of applicable commands is a divergence between two design philosophies that only becomes visible under load; single-type selection studies never surface it.
Where it stops holding
Context change should not make same-named commands have opposite consequences on similar objects, nor hide functions people need frequently. Multi-selection, nested objects, and empty space are especially prone to scope ambiguity — right-clicking an expanded parent node in a tree and choosing Delete, for instance, could mean the node alone or the node plus its expanded subtree, and without extra wording people can only guess, at the cost of an irreversible mistake. A context menu is also not a container for all global navigation: cramming an entire feature surface into right click leaves it invisible to anyone unfamiliar with right-clicking, or using keyboard or touch.
Applying it
- Make the target object and selection scope explicit through the menu title, an object highlight, or command wording — for mixed-type selections, state the scope explicitly ("Delete 3 items" rather than a bare "Delete").
- Keep only object-specific, low-frequency, or point-of-use valuable commands, with stable ordering for similar objects, so the same command does not shift position depending on the target.
- How to check: record menu content and the actual scope of effect separately for single selection, multi-selection, mixed-type selection, blank space, and permission-restricted objects, and look for cases where a command appears clickable but fires on an unintended object.