The monumental task of overhauling WordPress’ aging admin design is coming into focus, as contributors kicked off explorations of some initial mockups this week. Gutenberg’s Phase 3 is focused on Collaboration and this admin revamp is part of that road map.
As a starting point, Automattic-sponsored product designer Saxon Fletcher published some images and videos with a design that appears to have grown out of the editor’s interface to make it a more natural part of the admin. As part of the impetus for this project, he called out plugin developers that have introduced their own admin interfaces in the interim while waiting for WordPress to prioritize this project:
“The added risk here is that plugin authors are side stepping outdated UI by introducing their own which can further fragment the WordPress experience,” he said.
Fletcher emphasized that these mockups are “broad strokes and the first of many iterations.” The structural concepts Fletcher introduced include three main areas:
- A Sidebar for navigation
- A Page area for the main content, management, and settings
- A Frame representing the front-end of the site, which can be in an edit or read-only state
“The frame can be used for previewing any type of content, including your entire site, templates, patterns etc,” Fletcher said. “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 admin bar may also be getting a makeover as part of this project, although Fletcher did not elaborate on how it might change. The admin bar doesn’t appear in any of the mockups.
“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,” he said.
The initial mockups explore the idea of implementing a drill down navigation UI that can also be used to house basic content, but Fletcher acknowledged the challenges of navigating up/down the submenus more challenging. Design contributors are exploring workarounds for this, including introducing breadcrumbs or highlighting recently visited sections.
This concept for drill down navigation has received the most critical feedback in the comments of the post, as developers are concerned it will make navigation too complicated.
“Not a fan of hiding all the Admin Menus behind a maze of Breadcrumbs, also there are many complex UIs that will not convert well this idea for the menu system, the current benefit with our current menu system is that is very fast to change from one plugin to another or another area of WordPress with very few clicks,” designer Adam Pickering commented. “This proposal for the new admin menu makes that whole UX a lot more time consuming and frustrating for the user. Even if a proposal comes along where you put the previous menu item above the current position of where you are it won’t fix the issue as noted.”
Others are also concerned that the drill-down menu requires too many clicks and maybe even a popup menu on hover/long touch on mobile that pops out more options. Developer Anthony Hortin commented on how similar it is to the Customizer’s navigation:
As others have mentioned, this “drill down navigation pattern” would be incredibly frustrating to use, not only for new users, but experienced users as well. Not being able to see what options are under each menu forces the user to constantly click on each menu item, exit, click on the next menu item, exit, and so forth, until they find the screen they’re looking for. Even as someone who’s been using WordPress for 17+ years, I quite often have to hover over menus to remind myself where to find things.
This is also seen in the Customizer, which has had this style of navigation for years. When working on a new client’s site, it’s frustrating as hell trying to find options within the Customizer if they have a theme that you’re not familiar with. I would hate to see the whole Dashboard go in the same direction.
Participants in the discussion were also critical of the Frame concept for the admin, as most admin tasks don’t lend themselves to frontend previews.
“I’m most skeptical of the ‘surfaces’ approach and moving to a ‘front end first’ approach to things,” developer Jon Brown said. “Aside from theme edits, almost nothing I do in wp-admin requires or would benefit from a front-end view. If I’m managing orders on a WC site, I certainly don’t need/want to see the front end. If I’m editing plugin settings, again no front end. I get it makes sense for authoring new content, but that’s about it.”
As part of the Collaboration phase, Fletcher also proposed that the admin become more customizable for different use cases, so its navigation and system variables would make performing certain tasks more efficient for blogs, e-commerce, portfolios, and multisite, for example. He also hinted at the ability for the community to share their configurations.
“We’d like to see WordPress become a fun platform to build multiuser products on top of, more so than it already is,” he said.
WordPress developers will have a major transition ahead to make their extensions compatible with the new admin. Some individuals and teams are better positioned than others to make that step forward. Fletcher’s proposal recognizes that backwards compatibility will be an important consideration for not breaking settings pages for plugins that don’t get updated.
“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,” Fletcher said. “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.”
The discussion continues and the developer community is invited to weigh in on the initial concepts and structural elements proposed in the post.
