Until now, most explorations around navigation in the site editor have been a bottom-up endeavor. We’ve identified and designed solutions such as the mosaic view of templates and the drilldown navigation sidebar to connect disparate screens. But connecting these solutions and integrating them with the menus that already exist in wp-admin has been quite a design challenge.

In this post I’m in the clouds exploring this problem with a top-down perspective, and sharing some concepts that can theoretically serve us not only in the short term, but also the long term as we seek to elegantly deprecate wp-admin (😱) entirely.

It goes without saying that the chrome in these visuals is rough.

A single entry point

Currently the site editor is accessed through a menu item in the wp-admin navigation:

I am increasingly of the opinion that this is a sensible route on which to continue because it not only provides a designated area for experimentation in the site editor, but also avoids unnecessary interference with the broader wp-admin navigation structure, and consequently disrupting any existing user flows.

As an added benefit, when the site editor has 1:1 feature parity with wp-admin, then phasing out the wp-admin interface altogether becomes technically trivial (not accounting for plugins – one step at a time).

---

Up until now, most of the work done in the site editor has been focussed on template editing. This is a technical pre-requisite to more exciting enhancements simply due to the way that WordPress renders content. But now that we have most of the template editing fundamentals in place, perhaps it’s time to shift focus?

I’d like to concentrate on a more content-centric site editing experience. At the moment, when folks open the site editor we present whichever template is used to render the homepage. This can be confusing if you’re not familiar with the mechanics of WordPress’ template system (and let’s face it, the average user is not). It’s all too easy to conflate templates with content, and that’s before we even consider more nuanced features like template parts.

Content and Appearance overviews

Instead of dropping users directly in to a single template editing view, it might be better to display overview screens that can serve as navigational dashboards – not too dissimilar from what you’d find on a smartphone home screen.

Such screens could create intuitive compartments in which to present novel features that have a lot of perceived conceptual overlap, such as reusable blocks, template parts, and block patterns.

Here’s a (very) rough outline of what such a content management overview / home screen / dashboard might look like:

From this screen users are able to quickly access any recently-touched content in a single click. Shortcuts also also exist to draft new content, or to access environments in which you’re able perform less common tasks like bulk editing and trash management.

This view could be customisable in a number of ways:

• A scale slider could change the thumbnail size
• The number of items in each content row could be personalised, and the rows themselves re-ordered to suit
• Or perhaps even toggled row-by-row, based on user role or preference

As blocks enable authors to compose richer content layouts, a visual navigation experience like this increases in value and usability.

---

The video below demonstrates the three primary views a user would see as they open the site editor and drill down into editing a single item of content.

Appearance overview

While I believe the site editing experience should ultimately be content-centric for the majority of users, tasks relating to general appearance (like editing a template) still play a very important role.

In order to help clarify the lines that exist between content and template editing (something that is not always obvious), a dedicated appearance overview could be utilised. This screen would re-use components from the content overview to present entities that relate strictly to appearance, IE the active theme, templates, template parts, and perhaps block patterns too.

Once these views are implemented in the Site Editor, we’d have the flexibility to consider removing their wp-admin counterparts to drive adoption, if that was desirable.

Navigating between overview screens

If these overview screens serve as compartments for contextually relevant functionality, there must be a way to navigate between them. Perhaps the button in the editor could provide access to such navigation.

In the video below I navigate from editing a page, to the appearance overview, then the content overview, and finally back in to the original page.

You’ll notice the navigation panel also includes links to manage things like settings and users. This illustrates of how we might eventually migrate all site management tasks to the site editor, and create an opportunity to sunset the entire wp-admin interface over time.

This is where exciting possibilities present themselves, for example allowing users to configure exactly what screen they see when they log in:

Then I get carried away with other ideas like custom overviews for things like analytics. Or even apps like WooCommerce Admin that deliver their own suite of overview screens.