Action menu

Problem Context

• A row, card, table, selected set, page resource, or toolbar has more contextual commands than should be visible at once.
• The command list changes according to object state, permissions, processing state, or selection count.
• Users need to distinguish safe commands, links, disabled commands, bulk actions, and dangerous commands before activation.
• The trigger pattern already exists, but the menu content still needs taxonomy, labels, grouping, state, and outcome rules.
• The interaction must work for pointer, keyboard, touch, and assistive technology users without losing object context.

Selection Rules

• Choose an action menu when commands are contextual to one object, selected set, resource, row, card, or local page surface.
• Use a menu button pattern when the primary problem is trigger labelling, open state, popup ownership, focus movement, dismissal, and focus return.
• Use a button group when there are only a few important related commands that should remain visible.
• Use a command palette when commands are broad, searchable, shortcut-driven, cross-product, or not tied to the current object.
• Use a menubar when the product has a persistent application command hierarchy with stable top-level command groups.
• Use select, listbox, radio group, checkbox group, multi-select, or chip selection when the user is choosing values rather than invoking commands.
• Use confirmation dialog, typed confirmation, undo, or restore after a dangerous action is selected, not as a substitute for clear menu item labels.
• Use action sheet, context menu, drawer, or bottom sheet for platform-specific presentation when the same contextual command-list rules apply.

Required States

• Closed trigger or contextual entry point with resource scope.
• Open menu with accessible name that includes the object or selection scope.
• Sectioned menu state with headings or separators.
• Safe command item state with verb and object label.
• Disabled or unavailable command state with visible reason.
• External link or navigation item state when links are allowed.
• Destructive command state separated from safe commands.
• Bulk selection state that updates labels, disabled rules, and result copy.
• Processing or recently completed command status.
• Dangerous command review handoff state.
• Empty or no-applicable-actions state.
• Long label, narrow viewport, and high-zoom wrapping state.

Interaction Contract

• Every item has a clear verb, object, and outcome category: command, navigation link, checkable command, disabled command, or destructive command.
• The menu title, trigger label, aria-label, or nearby context identifies which resource or selected set the actions affect.
• Sections group commands by user intent or risk, not by implementation owner.
• Disabled actions cannot run and explain the blocker when users need that knowledge.
• Bulk selection changes item labels, disabled state, and result status so commands cannot silently affect the wrong scope.
• Dangerous commands are visually separated and either open review, confirmation, undo, restore, or another recovery path.
• Links disclose navigation or new-tab behavior when they can leave the current task.
• The menu closes after safe command activation and reports what changed.
• Focus return, keyboard movement, and dismissal follow the trigger pattern or platform action-sheet behavior.
• The compact action menu does not contain forms, complex editors, large previews, filters, or unrelated content.

Implementation Checklist

• Inventory commands by resource state, permission, selected count, frequency, risk, and recovery path.
• Name the menu by object or scope, such as Customer actions or Actions for 3 selected invoices.
• Write each item as a verb phrase with enough object context for repeated rows and screen readers.
• Group related commands under headings or separators when there are different scopes or risk levels.
• Separate destructive actions and define confirmation, undo, restore, or review behavior before implementation.
• Decide when unavailable actions should remain visible with a reason versus be omitted because they never apply.
• Update the menu when selection count, object state, permission, processing, or ownership changes.
• Keep icons optional, consistent, and secondary to text; give icon-only triggers precise accessible names.
• Avoid embedding form controls, search boxes, sliders, calendars, rich previews, and editable tables inside the action menu.
• Test row context, bulk context, disabled reasons, destructive handoff, keyboard focus, screen reader names, touch target size, zoom, forced colors, clipping, and portal placement.

Common Generated-UI Mistakes

• Treating the action menu as a junk drawer for every command that does not fit elsewhere.
• Using vague labels such as Open, Manage, More, or Delete without naming the object or result.
• Mixing commands, links, field values, filters, toggles, and form fields without role or visual distinction.
• Leaving disabled actions greyed out with no reason or recovery path.
• Letting a bulk action menu run single-object commands against multiple selected items.
• Putting destructive actions in the middle of safe commands with the same emphasis.
• Hiding primary or emergency recovery commands inside a menu while low-value buttons stay visible.
• Using icons as the only action names inside the menu.
• Failing to update menu content after object state changes, such as archived, locked, processing, or permission-limited records.

Critique Questions

• Can users tell exactly which object or selected set the menu will affect?
• Are commands grouped by meaningful user intent and risk rather than dumped into one list?
• Do item labels name the action and object well enough for repeated row menus?
• Are disabled actions either explained or omitted according to whether the user can recover?
• Does the menu update when selection count, permission, processing state, or ownership changes?
• Are destructive commands separated and routed through confirmation, undo, restore, or review?
• Is any menu content actually a form, filter panel, settings page, or value selector that needs a different pattern?