Menu items must stay in sync with actual availability

What it is

If a menu item is lit, invoking it should actually work; if it is dimmed, it should not work now. Sync with actual availability means clickability on the menu tracks the current document, the current selection, and the current permission—not a still image computed once when the menu first opened.

Desync has two faces. Lit but failing: someone chooses Paste and gets a beep or “not now.” Dimmed but possible: the selection already qualifies, the item is still stuck on last time’s disable, and the feature is taken as broken.

Why it happens

The menu bar is read as a gauge of present capability. In the moment the menu opens, people read “what I can do now” and then decide whether to click. If that reading lags the true state, the decision uses a stale gauge. Lag comes from caching: enablement computed on window activation and not recomputed on selection change, or an async permission that returned and never refreshed the items. A desktop menu can open before the pointer goes down; hundreds of milliseconds then pass before the click. If a collaborator changes the selection in that gap, the click still has to run against the state at press, not against the snapshot from open.

The sting is that the menu just claimed the action exists and is available. Toolbar buttons go stale too, but the menu is read as a complete inventory, so one stale row contaminates trust in the whole catalog: people stop believing the dimming.

Where it stops holding

Slow permission checks (network, hardware) cannot finish in the frame the menu opens; an “unknown” that flips to the true value quickly is allowed, a long stay on the wrong true value is not. Local conditions—read-only document, empty selection, empty clipboard—should be computed before the menu opens. Demo or recording modes that freeze the menu for a clean picture are a temporary false gauge and must thaw when the demo ends. In a multi-window app each window’s menu follows its own document; do not paint the next window with the previous window’s availability.

Applying it

• Recompute item enablement on selection change, clipboard change, and document-permission change; do not compute only at launch or on window activation.
• If a command that was shown as available is no longer available at the click, treat it as a failure and say why; do not swallow it.
• Verify: select some text, Copy should light; clear the selection, Copy should dim. After a copy, switch to a read-only window, Paste should dim. Change the selection under an already-open menu and invoke a still-lit item: the result must match the state at the click, not the state at open.

Related

• Within the group: K2.03.1 The menu bar is the complete inventory of commands · K2.03.2 Menus are the main channel for discovering commands and learning shortcuts
• Adjacent: K2.09 Menu Bar and Command Organization · D1.07 Disabled state
• Search terms: menu enablement · stale UI state · command availability