Admin Design

This is part of the Phase 3: Collaboration roadmap. The main projects are Real-Time Collaboration, Workflows, Revisions, Media Library, Block Library, and Admin Design.

Introduction

About a year ago, some early notions of how we could evolve the admin experience were shared. The site editor, and the foundation set by its fluid browsing and editing flows, provides a pathway for revitalising the adminadmin (and super admin) experience. Given all the workflows and collaboration requirements through the upcoming phase 3 projects, it’s time to look more in depth at these ideas and where they might lead.

There are multiple goals to account for with this effort. The state of the art and user expectations for digital software are constantly changing and there’s a tangible need to revitalize the wp-admin design, improve its visual clarity, reduce cognitive weight, better support user workflows, and expand the personalization of the interface. WordPress thrives within its flexibility and its 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 ecosystem. The counter part to that can often be a complicated information density, particularly at the top level navigation, which can negatively affect the user experience — we’ve all seen admin dashboards with very long and daunting sidebars!

As WordPress turns twenty years old, the overall aim of this work is to improve upon this experience at a foundational design level, giving plugins and users more control over the navigation while ensuring each WordPress experience is recognizable, intuitive, accessible, and delightful.

So how can we design the overall admin in such a way that it can be shaped to any need, regardless of their simplicity or sophistication? How can we then manage complexity without being complicated? How can we make designing and building great interfaces on the platform easier and more expressive to usher it through the next two decades? This balance cannot just be achieved with good practices but needs to be reflected in the semantics and the design of the software itself. For example, offering a way to customize the most important menu items at the highest level might allow both a blogger and a commerce store manager to have the best possible experiences, without trading compromises. Shaping WordPress to the particular needs of each person and project can be a large part of ensuring its continued long term success as the operating system of the web, democratizing access, and championing a diversity of experiences. The challenge is doing it without sacrificing the important aspect of good defaults and the “it just works” ethos.

In order to achieve this we’d want to clarify some of the main extension points as semantically as possible. What structures and surfaces does WordPress provide so that plugins and platforms can make use of them to achieve their visions? What does it mean to register settings, sections, or to add blocks? What elements of the interface are relevant? How can they be navigated? This is crucial to establish not just for ease of development but to ensure a usable and accessible experience for all.

This effort is also an opportunity to formalize the design primitives and interaction paradigms that are part of the UIUI User interface component system begun in wordpress/components. A crucial aspect is to ensure WordPress itself is built with the same pieces and APIs that plugin authors can use. Aside from color themes, our set of primitive components also need to work in dense environments like the editor, as well as environments that need more breathing room and focus like admin sections. Density, clarity, usability, and 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) are paramount. A related discussion can be found here. As part of leveraging the components across the admin interface, we need to address functional gaps (like table and list views, bulk editing operations, etc) and assist plugin needs for anything that might not be already addressed that should be addressed. Ultimately, the design library needs to be showcased in the wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ website as a clear resource for people building upon WordPress. A great developer experience should naturally guide people to accomplish great and consistent user experiences.

Another primary goal is to achieve a cohesive experience between all editing and management activities. It goes without saying, but navigating through your tasks should feel seamless, whether editing with blocks or managing settings; going through default WordPress sections or plugin areas; or whether the user is operating as an author or an administrator. Considering the space afforded by a malleable browsing experience, combined with the collaboration work, it’s also a good opportunity to look at how offline support might work and its implication for handling optimistic interactive updates to user data. There are a lot of great efforts — from Playground to SQLite — that could also align to provide a fantastic platform experience with all the modern expectations for speed, access, and performance.

Scope

There remain a lot of open questions to work through before going into further technical details but the following should offer an outline of some concrete aspects to consider as more in depth design explorations are done:

• Define the structural pieces of the admin experience, from a design and instrumental perspective. Formalize its semantic extensibility. What structures and surfaces does WordPress provide so that plugins and platforms can make use of them to extend and reduce what’s possible?
• Restructure admin menu design to support a drill-down interactivity model. Leverage and augment existing APIs for maximum backwards compatibility. Explore using the frame as the encapsulated target destination for existing admin views.
• Look into user personalization with the ability to reorganize top level admin menus. It could work in a similar fashion to “pinning” plugin sidebars in the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor, where both plugins and users are in control. Also consider coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. sections on the same level so that they could be toggled on or off based on needs.
• Deep accessibility support for navigating regions, tuning global preferences (like button text labels over icons across the UI, and other affordances) as part of further refining each user experience according to people’s needs and preferences.
• Look at wider deployment of Command Palette across admin sections and formalize its APIs.
• Introduce more semantic placement of quick actions: for example, organize all “add new” options and hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.; place notifications, user profile, other top level extension markers, and so on.
• Work on completing and evolving the design system gaps. Develop set of components to handle table and list views. Introduce full theme color support. Consider what sort of requirements for SSR are relevant.
• Revise the design of general settings views by applying and structuring these components.
• Look at the current role of the dashboard home and perhaps embrace admin blocks for improving its widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user.-like personalization. Improve built-ins like quick posts, post formats, and title-less posts as outlined in the workflows project.
• Connect with notifications project and a path for reducing ad hoc notices across the admin.
• Look into the implications for multi-site networks and its navigation patterns.
• Address the state of front-end admin bar or equivalent.
• Contemplate solutions that maintain as much backwards compatibility as possible for admin sections that may never be updated by the original authors.

Get Involved!

Please, share any feedback, ideas, or requests you might have as we embark on this road. Every voice in the WordPress ecosystem should be reflected in this work as we balance all the different needs and expectations.

#gutenberg, #phase-3