Menu contents change with the selected object
Aliases: object-action menu · right-click menu
What it is
A context menu is a command list invoked on an object, whose contents are decided by that object. Select an image, and Crop and Set as cover appear; select a span of text, and Copy and Comment appear. The menu is not a shrunken global command set. It is “what can be done to this object now”. When the object changes, the list should change; when the object does not, the list should not suddenly swap.
Why it happens
People treat the menu as the verb list for that object. The invocation site (right-click, long-press, secondary click on the object) pins the target, so every item in the menu eats this object by default and no extra scope selection is needed. That is shorter than finding a command in a top bar and then confirming who it acts on. Because scope is fixed by the object, the menu must filter by type, state, and permission: a folder has no Set as cover, an archived thread has no Reply, Delete on a read-only object should not still look pressable. Under-filtering means people only learn a verb is illegal after choosing it; object–verb matching fails after the fact. Over-filtering means two objects that look the same pop entirely different lists, and people think they hit the wrong object.
Multi-select changes the list’s semantics: it must commit either to the intersection (verbs every selected object can take) or to the first object, and stay consistent. Sneaking in global items unrelated to the object (Settings, Help) turns the context menu back into an ordinary menu and blurs scope.
Where it stops holding
A context menu on desktop empty space targets the canvas or window, not “nothing selected”. On touch, if object hit-testing is unstable, the list will not know who to eat; an explicit button on the object is cleaner. In live collaboration an object’s state can change after the menu opened (someone else locked the file); an item legal at open may be illegal at press, and must be re-checked before execute. Keyboard invocation should aim at the focused object, not the one under the pointer, or the mouse and keyboard models will fight.
Applying it
- Build the menu from object type and current state, and put only verbs that mean something on that object. Unavailable items are removed, or left with an immediate reason — do not wait until press to fail.
- On multi-select, default to the intersection of verbs, and mark in the title or first row how many objects are in scope.
- Do not park global navigation or help inside an object menu; those have their own entries.
- How to check: invoke once each on two object types, two states of the same object, and a multi-select, and check that verbs cover only that scope. Any “pressed, then told it cannot” or “two look-alike objects, unexplained totally different lists” means context did not pin.