As we further develop the primitives that make up the overall admin system (#53322) it seems important to map out the main elements that compose it. This issue focuses largely on how things might work and how things are structured, not how they look.

We'll start, for the sake of the presentation, with defining Materials, Concepts, and Screens. Materials are the places where Concepts are rendered; Concepts are the interfaces for the various items a site needs to represent; and Screens are the dedicated routes that bring them all together and construct the various user flows.

The terminology is just an instrument to help us break things down. The main thing to capture here is that the admin is composed out of a few shared pieces to account for the needs of extensibility, personalization, flexibility, and consistency.

The Materials

The overall Admin user interface is composed of a few core materials, grouped into Base, Surfaces, and Overlays.

Base

This is the base layer of the interface. It can change colors between light, dark, or user defined color palettes. The base layer contains the following items:

Surfaces

We define three main element that build up the various layouts of the admin screens.

• Canvas
  The primary area for previewing and editing content (e.g., block editors).
• Stage
  Harbors either a Library of items (posts, pages, media, products, orders, patterns, fonts, etc) or Settings. This is also the main area for plugins to develop more customized interfaces.
• Inspector
  Is meant to be a narrow (possibly fixed) width element for quick edit panels, style panel, editor inspector, plugin sidebars, etc.

Overlays

Includes modals, preferences, dialogs, and interfaces like command palette.

The Concepts

Each surface can bring together a set of reusable, high-level concepts. These are primitives that define structure and functionality. Most of these already exist in code and have been the main focus of development as they tie in with the component and design system in encapsulating functionality, user interaction, accessibility affordances, etc. These are not meant to be exhaustive, just a high level grouping of the most common elements.

• Navigation
  Menus (dropdowns, drilldowns), drawer, tabs, item groups.
• Collection
  Lists, grids, tables, and alternate layout representations of DataViews.
• Forms & Settings
  Structured fields, validation, form layout (e.g., DataForm, ToolPanel). (Fields API meets component system.)
• Block Editor
  Context-specific editors for entities like posts, templates, and patterns.
• Widget
  Small units laid out in a grid that connect with various functional components to create a personalized dashboard experiences.
• Inserter
  UI for adding new blocks, new post types, new templates, etc.

The Screens

With these building blocks in place, every Admin screen can be declared as a layout incorporating these surfaces and concepts. This modular approach helps us ensure consistency, flexibility, scalability, and clarity across the entire admin and plugin experience. The layouts themselves are not fixed but starting points, since they can be reconfigured by plugins or by the user through data view configuration.

Illustrative example: Pages...

These are a few wireframes of how it comes together for a specific screen like "Pages" and all the ways in which it can be configured.

List view with canvas showing full template preview.

List view with canvas showing abstracted template preview (template is hidden, it only renders title and content like the default editor).

Table view

Table view with quick edit / bulk edit open.

Grid view with quick edit / bulk edit open.

And the way we would describe this as a layout is something like the following:

Pages:
    Stage: Lists + Inserter + Tabs
        Default: List, [Table, Grid]
    Inspector: quick-edit
        Default fields: [ Title, Slug, Parent, [...] ]
    Canvas: block-editor
        Default view: Template, [Abstracted View]