Situational items should change availability, not disappear

What it is

With no text selected, Cut should still sit in the Edit menu; it simply must not run. Disable rather than remove is an organization method: the command keeps its place, and disabled state means “not now.” Deleting it from the menu makes people think the product has no such command, or that they remembered the wrong slot. That a menu item must match whether the action can actually run is a separate requirement. This entry is that when it cannot run, the item should show as disabled, not vanish from the inventory. Entrances that must not exist at all for this principal are out of scope.

Why it happens

A menu is an executor and a map. People retrieve commands by place (middle of Edit, above the separator). Items appearing and vanishing change the map’s geometry: later items slide up, remembered coordinates fail, and infrequent users cannot tell whether “I don’t see it” means it does not exist or today’s situation is wrong. Disabled splits “exists” from “runnable now”: the name stays, the slot stays, and unavailability itself is a note about situation—usually no selection, no open document, nothing to undo. Hiding welds those two facts together, and the map jitters on every selection change. State sync that only means “don’t look clickable when it won’t run” can still be implemented by hiding. This claim requires that the sync be implemented as disable.

Studying it

Compare two menus: hide the target when the situation fails, versus leave it in place and disable it. Tasks include “with no selection, have people confirm where Cut lives,” then give a selection and run it.

Independent variables: hide versus disable when the situation fails, whether a disabled item carries a reason, whether hiding shortens the menu enough to notice. Dependent variables: whether people can point to the command with no selection, time to hit it once a selection appears, whether they hunt other menus or Settings for a “missing” item, judgment of “does this product even have Cut.”

If the task sheet says “please Cut,” people will hunt hard and discovery failure under hiding will be undercounted. Stabler: first ask “can this software cut, and where,” then operate. Touch long-press menus are already short; hiding there is not comparable to a desktop menu bar and should be reported separately.

Where it stops holding

When a menu is already long enough to scroll, chronically disabled items crowd out what can run now. Rarely satisfied items can move into More—and should still be disabled there, not deleted, so the map does not grow holes. Capabilities whose very name must be withheld from this user should be hidden: that is permission disclosure, not situation. Context menus are assembled for the current object and are expected to swap their set; a menu bar is not expected to, and must not delete items as the selection changes. Games and stories that unlock abilities per level may introduce a command from nothing the first time; after that they should switch to disable, or the map jitters again on replay.

Applying it

• Keep commands that vary with selection, document, or clipboard in the menu bar’s slots; disable them when the situation fails, do not pull them from the list.
• Where there is room, say what is missing on a disabled item (no selection, no document, nothing to undo); do not only gray it.
• If the same command is also a toolbar button, disable both together; do not let it vanish from the menu while the button stays lit, or the reverse.
• Verify: clear the selection, open Edit, and confirm Cut/Copy still occupy their slots and cannot run. Note their neighbors. Select text; the neighbors must not move. Ask someone new to the product, with an empty selection, whether it can cut and where—pointing at the right slot means the map is intact; a trip into Settings means hiding taught them “it isn’t there.”

Related

• Within the group: K2.09.1 Group commands by use situation, not by development module · K2.09.2 Deep menu nesting makes infrequent commands undiscoverable · K2.09.3 Command names must match terms used elsewhere in the UI
• Adjacent: K2.03 Menu Bar · E5.18 Permission visibility of navigation items
• Search terms: grayed-out menu · disable versus hide · situational availability