Original issue by @fcoveram, bringing it to Github with designs, all content below is by @fcoveram

In the scope of making progress on the command palette capabilities for WordPress 7.0, @fcoveram worked on a proposal that aims to define the role of the layout and the pieces it is composed of, classify the actions displayed, and outline two patterns for two action types.

Proposal

The design explored is heavily based on Raycast as its simplicity addresses the content and interaction needs we have expressed.

The layout is divided into three sections: header, content, and footer. The Header is where the search, back , and editing text take place. The content part serves the list of actions and the static output. The footer provides actions related to the content displayed.

Given the importance of context when triggering the command palette, it seems relevant to show action categories for recent actions, favorite actions, and actions suggested by the system. The amount of these and the mechanics for adding/removing them is pending, but the core idea is to provide quick access to recurrent actions such as moving between documents if user is editing a template and a post, or trigger settings in the editor when editing a document.

Most options displayed will be actions, but in some cases, drilling down allows quick access to a set of commands or to the resulting commands coming from a main one.

We can divide the actions into:

• Command (ability): The basic action that executes a code.
• View (previously Section): A link that takes users to a specific area in the admin.
• Edit: An action to edit a document, or one or multiple fields.
• Workflow: A sequence of abilities that generate a static output.
• Action: A generic, uncategorized command, should only be a fallback.

Each action consists of an icon, a name, and a type. For the wide range of actions the command palette can display, I think the icon should reflect the action type rather than being tied to where the user lands. In that case, the plus icon can quickly indicate adding a post, page, block, or media item.

In the current command palette, the structure of the action label communicates what the action does, but since the action type already indicates the type, the name could be a short version of the “breadcrumb” or the location in the admin where the action will happen.

Here below are examples of the action types.

Since the design, Section was renamed to View.

Interactions

So with these two ingredients, the default state and action types could work in the following ways.

Default view

Navigation

Edit

Tasks:

• Add categories to registerCommand API.
• Add categories to the command palette UI.
• Add sections to command palette (recently used, favorites, search drill down).
• Consider adding on-the-fly editing for common things (inline DataForm).
• Introduce a dev note instructing plugin authors to add a category to their commands, with 7.1 starting to emit console warnings for commands without a predefined category.
• Update the command palette from using cmd+k to using BaseUI autocomplete component or something similar from the design system.
• [ ]