Phase 3: WordPress admin redesign

[SaxonF]

admin-explainer.mp4

admin-direction.mp4

Consider this a tracking issue to monitor progress as we build out and refine different aspects of the admin redesign. If you haven't already, please read through this and this to gain a better understanding of the project

Navigation

The navigation paradigm we adopt is a central part of the experience and impacts everything around it e.g. page layout. The site editor currently makes use of a drill-down pattern where as classic admin adopts a flatter, more persistent approach. One of our early priorities should be solidifying navigation.

• ...

Surfaces

A user generally works on either the front-end or back-end of their site. Sometimes tasks on the back-end affect the front-end and vice versa. How are these two surfaces represented in admin? Site editor introduced the idea of "The Frame" which offers a view of the front-end of your site at all times allowing us to show the impact an action on the back-end has on the front-end. It has the potential to be an iconic/brandable element of WordPress moving forward.

Surfaces can be seen in a similar sort of light as Windows or Volumes which are emphasised in Vision OS.

Our goal for this track of work is to explore how and align around how these surfaces should be used and configured in different ways.

• ...

Notifications

How might we elegantly inform users of important information in a way that isn't overwhelming?

• ...

Customisability

We’ve all seen how the WordPress experience can be polluted by ever growing top level navigation, notification stacks and fragmented settings screens. We need to offer a level of customisation that gives site creators (or platforms) the ability to shape the information architecture and character of admin to best suit a particular use case. Even better, how might we make it easier for the community to share their configurations with others?

• ...

Backwards compatibility

Perhaps the trickiest part of this whole initiative is rolling admin changes out in a way that is iterative, doesn’t break existing workflows and encourages gradual adoption. The site editor has given us a space to experiment, including being able to browse your site’s pages in the latest 6.3 release, and that may extend to other core admin pages like site settings, but at some point we’ll need to “break out” of the editor to prevent too much duplication. We also need to support plugin pages that may never update, and do it in a way that feels seamless.

• ...

Design system

Due to the customisable and extendable nature of WordPress admin its important it has a strong system at its core.

We should aim to iterate on the existing WordPress components package which can evolve into a fully fledged, themeable system with accessibility baked in that plugin authors can refer to and make use of. This also includes variables for generated color scales ( ideally with a high contrast option), spacing, shadows etc. We have a unique challenge in that we need to cover dense environments like the editor, as well as environments that need more breathing room and focus like admin.

Tokens/Variables

Variables make up the foundation of the system and give admin its character. Our set of primitive components need to work in dense environments like the editor, as well as environments that need more breathing room and focus like admin.

Colours

The current Gutenberg colour system has been great for the editor, however we are starting to see the limitations while designing for a dark surface. If we want to lean heavily into customisation, and support themes including dark, we may need to extend the system and take a more programmatic approach.

• Design and implement a new colour scale

Other values

Let's audit existing variables and decide whether we need to refine. Shadows is one that needs obvious attention.

• Radii #63703
• Shadows / Elevation #63757
• Systematising typography styles in the admin UI #64340
• Font families
• Spacing
• Width (e.g. containers )
• Height (e.g inputs, buttons)
• Z-Index

Primitives

• Dropdown supporting nested menus
• Align checkbox, radio, and toggle input design #63490
• Update the Button component #63856
• Overlays (color, opacity, blur?)

High level components

We then have a set of components at varying levels that make use of these primitives. These include page headers and general layout, filter bars, pagination etc. In a lot cases these may just be considered patterns that provide guidelines around how primitives should be composed in different scenarios, and not literally a component to be imported.

• Page layout and header
• Table
• Filtering, sorting and views
• Grid
• Pagination

Patterns

• Admin redesign: Settings #63624
• Lists
• Post type editing

Guidelines

Finally, to help create consistent experiences and improve adoption of the system we should be documenting guidelines and best practices. There is work to be done to update the existing design handbook as work here progresses.

• Tracking issue

Accessibility

A benefit of a well designed system is that accessibility should be largely baked in including in documentation/guidelines. Colour scales should provide the right amount of contrast, primitive components are all keyboard and screen reader accessible, and documented guidelines encourage usability best practices.

[SaxonF]

Re Guidelines/Accessibility. I really like what Shopify have done with Polaris and how accessibility guidelines is also quite contextual (e.g. see Combobox. At the moment our design handbook and accessibility handbook feel quite separate.

[joedolson]

I would love to see better integration between design and accessibility documentation. Let me know what you need from me to help make that happen.

[karmatosed]

@SaxonF do we want to have an issue for auditing existing components and various areas of WP's needs? For example, we might be able to not only spring clean a bit but get something in others use so many different libraries for now and raise those ships!

[SaxonF]

@karmatosed 👍 any sort of auditing would be helpful. We are beginning to see some auditing in the page layout and Table issues but don't currently have a more general space to share patterns/components we haven't captured yet. Could either just collect general insights here or create a separate issue as you suggest . I don't have a strong preference.

[annezazu]

Updated to this an Overview issue as it covers a large body of work that's expected to broken down into various tracking issue to accomplish!

[fabiankaegy]

I just started a new Discussion to explore whether it would make sense to think about a framework for building out react-powered settings pages sooner in the whole Admin Redesign timeline here: #62094

I would love to get your thoughts on this :)

CC: @karmatosed @youknowriad @SaxonF @annezazu @noisysocks

[youknowriad]

@fabiankaegy I think when we'll advance with #59745 we'll find ourselves in a place where we actually have a framework for doing that. So these two things might end up being the same thing.

[lgersman]

A JSON Schema Form renderer might also be a usefult option to use in the redesigned admin interface : #62094 (comment)

WP Playground Link to see a Gutenberg based JSON Schema Form Renderer live in action : https://playground.wordpress.net/?blueprint-url=https://raw.githubusercontent.com/IONOS-WordPress/cfhack2024-wp-react-jsonschema-form/wp-now-support/playground.json