These are some very early concepts around evolving the admin interface which are meant to spark conversations towards defining the outline of Phase:3. Some of the ideas presented here emerged when trying to solve problems around the site editor but have much wider breadth and consideration.

Given the third phase of the current WordPress roadmap has a focus around workflows and multiplayer, considerations around the various admin flows become all the more important. Also, as the component language introduced through wordpress/components becomes more established, we need to contemplate its coherent expansion outside the editor views.

Please, note that nothing here is meant to be settled in any way; it’s just a gathering of thoughts and possible paths to be explored in the future for early feedback.

The Shell and the Canvas

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 introduced a full-screen view as the default experience. Any such presentation faces the challenge of how to contextually access information outside the main frame. In the site editor context, this meant accessing templates and navigation. For the post editor, it might be accessing the list of posts or pages. This is generally characterized as “going back” but such a characterization falls a bit short and should be challenged.

One idea that has been surfacing is that we are dealing with two materials at different layers of focus or distance: the admin frame (or shell) and the canvas that contains the content or site representation. The canvas could be in a zoomed state — essentially taking the available space of the screen — but it doesn’t mean the navigation tools are in some “back” state, they are just off view at the present moment. If we were to zoom out from the full-screen state we would naturally get to see where we currently place in the stack.

For a practical application of some aspects of this idea see: https://github.com/WordPress/gutenberg/issues/36667

Articulating these materials in ways that can go from an edge to edge screen representation to complementary partial displays within one system becomes an interesting way of thinking through the problem of achieving focus, context, and clarity. This obviously has further implications on how we reason about keyboard navigation and screen regions.

In the context of the block editor, the canvas is naturally a representation of the site or content, but the canvas frame should be flexible enough to accommodate other types of admin views that are oriented towards management or settings. This also has implications for backwards compatibility since the expectation is that existing views can be automatically accommodated.

The Home Button

Since we are articulating different levels of focus, the home button (represented by the site icon on these prototypes) aims at being a permanent fixture that allows escaping the inner most level of focus and jump upwards in the navigation stack as needed.

When in full-screen, the home button reduces the frame to a smaller footprint and displays the current level of navigation within the shell. The home button is thus defined as a contextual interface element, that can be pressed further to go all the way back in the stack to the initial dashboard. The aim of this interface element is to both give control and build familiarity to navigate away from any context. There are some details of this mechanic to consider and refine if it were to serve its purpose.

Make it ExtensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software.

The system needs to be naturally extensible. The basic mechanisms for registering menu items are already in place, but we’d need to reason and give more formal access to the canvas and shell properties, as well as the ability to model its various states.

There are many ideas left to explore here. For example, plugins that might need to operate like applications could colorize different sections. They’d get access to the frame in its various configurations so it can use it as primary 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. for management views, or as an editor canvas, etc.

Worth noting that some activities — like dealing with the theme design, for example — might clash with user chosen color schemes on a fundamental level. However, given the shell is adaptable, sections such as “design” could establish themselves with its own muted palette, either dark or light variants, and so on.

Make it Personal

Almost every computing context of sufficient scope and generality would eventually recognize that to be the best experience for every user it needs to allow some degree of personalization. The WordPress admin has allowed this primarily through code APIs and in ways that are not generally the most intuitive or that require effort to coordinate. This brings a tension in discoverability and how overwhelming the navigation experience might get to be.

One important idea embedded in this proposal is allowing the set of main navigation items to be configurable, either as shortcuts or as pinned items, similar to how the block editor handles 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 extensions in the headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.. This would allow a more systematic and maleable approach to choosing what are the most important items for a given site or a given user flow.

A corollary is that different users could have different admin experiences based on what flows they use and care the most within the same site.

There and Back Again

There are various cases where jumping transversally from one area of the admin to another become important. It’s not generally convenient to map all the path combinations for going from point A to point Z (and everywhere in between) without also exploding the cognitive complexity.

It would be interesting to consider recently visited areas as some sort of stack, similar to Command/Control+Tab interfaces in operating systems, but operating for recently visited sections of the admin interface. This is just a the pie in the sky thing for now, but imagine if the few places you visited where represented in the frame stack somehow (as dots, as stacked frames, etc) so you could easily swap places without having to traverse layers of menus each time if you need to be bouncing between a couple specific flows.

Search

The ability to jump to a section, plugin area, or content piece is a powerful model that has become more ubiquitous in modern applications, often in the form of a “command palette” or equivalent quick-access interfaces. It’d be worth mapping how a feature like this could work in WordPress and how it could leverage the very same APIs we use to define menus, locations, settings, and content types to become extensible. While this is becoming a more familiar pattern for going to a specific location or entity, it’d probably remain an advanced feature in nature and thus a secondary affordance.

Multiplayer

When Phase:3 is mentioned there is a strong emphasis in the ability to work with others. This means both real time collaboration as well as asynchronous ongoing collaboration by multiple user roles. Taking these capabilities into account into the very fabric of the admin experience is one of the reasons for considering the admin flows as all encompassing. Multiplayer might be reflected in both the editor frame and the management views. Imagine not just being able to collaborate on a page or a design but to also be able to follow the avatarAvatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. of a person and jump straight to where they are in the admin so you can collaborate on any activity. There’s a lot there left to explore and unpack.

Thanks to @jameskoster and @joen for the work on some of these early prototypes.

#gutenberg, #phase-3