Want to get involved? See the handbook and optionally drop into #design to chat. Most active design work happens in the block editor project, consider dropping into Needs design or Needs design feedback.
There’s a WordPress Component Library in Figma. Duplicate to edit, direct access is reserved for the design team.
Thank you to everyone who contributed to this work so far, either directly or indirectly. This includes @jameskoster @joen @richtabor @matveb @annezazu and many many more.
This is a follow up to the recent admin design post on Make CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. which highlights the need for us to start thinking about what an evolution of WordPress admin might look like. The release of 6.3 gives us a hint of what’s to come via the Site Editor, so it’s time to chat through some of the core concepts explored, collect feedback, and begin to think through how to break this significant effort down. Consider what you see here broad strokes and the first of many iterations. It’s going to take time to get right.
It’s first important to understand why its worthwhile spending the time on a large initiative like this. How might it allow WordPress to continue championing the open web and keep an edge on proprietary tools?
As products expand in functionality so too does their complexity. This is a common software challenge that WordPress also faces, particularly because we have so many different types of users, including end users, site managers, builders, agencies, pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party builders etc. WordPress admin is the glue that ties together the different stages of a user’s journey, from setup to content creation to management and monitoring, which means it plays a critical role in helping to reduce the overall complexity of that journey. The added risk here is that plugin authors are side stepping outdated UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. by introducing their own which can further fragment the WordPress experience.
How might we introduce new paradigms/mental models that make WordPress that much easier to use?
WordPress can be shaped to cater to a wide range of use cases, but this opens up an interesting design challenge (and opportunity) to ensure we are properly serving each use case well enough. We have an opportunity to take customisation and even private labelling to the next level.
How might we design WordPress in such a way that it can be tailored and rebranded to a point where it feels like an entirely new product focused on a specific use case?
The success of a product largely depends on the perception of its brand. The way people perceive WordPress, particularly developers and designers, has gone through a lot of change over the last 20 years. Sometimes, it’s taken for granted or dismissed as old software. If we want WordPress to continue to be successful we need the next generation of creators to reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. positively to the mention and use of WordPress. Surface details such as visuals/UI (both in product and marketing) are are a direct extension of the brand, as is usability.
How might we use this an opportunity to help reinvigorate the UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. and attract a new audience?
Now let’s get into the fun stuff and talk about some of the various concepts explored so far, some of which we can already begin to see in the Site Editor.
As WordPress has evolved, the connection between admin and front-end has only gotten stronger. GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ introduced a WYSIWYGWhat You See Is What You Get What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. way of working, and the Site Editor extended that to all aspects of your site. 6.3 now completes the connection by bringing your site into parts of your admin experience via what we call “The Frame”. We are starting to see a new paradigm emerge that is not unlike mail and note taking experiences where content is in view alongside navigation and management based tasks, unlocking a new way of working.
It’s important we identify the different surfaces of WordPress and what their roles are so that end users feel comfortable moving between them, and developers feel comfortable extending them.
Exists “under” the preview of your site. It’s what powers everything above. It can be broken down into two, extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. areas.
The sidebar should be used primarily for navigation as well as house simple, high level tasks that benefit from having the front-end of your site in view. Zoom in to the editor for granular edits and zoom out for broader strokes.
If you need more space than what the sidebar provides for a particular task, you can make use of the main content area. Examples being bulk editing posts, adding new products, managing a media gallery or pattern library.
The frame represents the front-end of your site and can be in an edit or read-only state. It sits above admin and can be used to show what impact an admin change might have on your site. It can either be in a primary or secondary position, or not visible at all.
The frame can be used for previewing any type of content, including your entire site, templates, patterns etc. Plugins can decide as to whether they benefit from having the frame in view while a task is being worked on, or hidden away. If a plugin doesn’t make use of the main content area, the frame will be in its expanded state.
The command palette is a power-user tool that sits on top of everything and is aware of what’s beneath it so that it can offer contextual actions and information. This also becomes a place for a user to “talk” to WordPress via natural language interfaces. Plugins will be able to register commands that may range from a simple shortcut to interacting with AI chatbots or wp-cliWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ interfaces.
Between these surfaces lie the connectors that help users transition between them. The most obvious and important example of this is the admin bar that’s currently visible on the front-end of the site. With the introduction of the frame, which represents the front-end of your site, we have an opportunity to re-think what transitioning between the front and back of your site looks like.
Core and plugin authors should be able to make use of the surfaces outlined above in different ways depending on the job at hand. Let’s take a look at what configurations might be possible and where they would be useful.
In scenarios where a simple task in admin changes the front-end of a site you might be best served by hooking into the sidebar and previewing changes in frame. This is ideal for onboarding, site or page settings, or even hyper-focused editing experiences.
You can combine the use of sidebar and content for tasks that are more management orientated and require more space with multi-layered navigation or filtering.
For simple management tasks that are only one level deep you can simply make use of the content area.
A more exploratory concept depicts all three areas in combination, with the frame in a secondary position that can be called upon when a document’s presentation requires editing. However, there are questions as to whether there is an elegant way to pull this off.
There are some scenarios where none of the above are appropriate and content or a task deserves its own space or focus. Modality is a useful technique here that includes full screen modals ideal for multistep tasks like setup/onboarding flows. Core should aim to provide patterns that plugins can make use of to keep focused experiences consistent.
We’ve introduced a drill down navigation pattern within the Site Editor which can apply to the rest of admin. There are pros and cons to this approach. It provides greater focus and the space can be used to house basic content alongside the frame or main page area, but it does make navigating up/down the IA tree a little more challenging. We are exploring ways to work around this, for example introducing breadcrumbs or highlighting recently visited sections.
As part of this work we should aim to iterate on the existing WordPress components package which can evolve into a fully fledged, themeable system with accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/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. This deserves its own dedicated post but in the meantime you can view and contribute to this tracking issue in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/.
Combining all the above offers a tremendous amount of flexibility that can cater to a wide range of use cases. However, we’ve all seen how the WordPress experience can be polluted by ever growing top level navigation or 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?
Let’s take a look at a few different use cases and how they would benefit from customisable navigation and system variables. We’d like to see WordPress become a fun platform to build multiuser products on top of, more so than it already is.
This ability to customise admin adds more value to multisite setups, which also have to fit in naturally with this new admin experience.
It’s important for admin to be scalable down to mobile devices where site monitoring and administrative tasks will be done on the move. There are some details to figure around how to call upon the frame when out view.
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.
Once we’ve aligned on the high level concepts we can follow up with a few other posts that dive deeper into some of the details. Notably:
There is a lot of excitement and potential surrounding an admin redesign and how the Site Editor can act as a safe entry point to the work, but there are many risks and potential rabbit holes as well. We need to lean in to existing insights and feedback and as much as possible, starting at a high level. Low level details like UI components (lists, tables, filtering, settings pages etc) can be discussed directly within GitHub. With that in mind, here are a few questions for the community that will help progress this work forward.
You must be logged in to post a comment.