James Koster

With the advent of the site editor and all of its associated blocks – not to mention the burgeoning catalog of core blocks – the Inserter is starting to feel a little disorganised.

We have block categories for “Theme” and “Design” which feel conceptually at-odds with one another (in case you’re wondering “Theme” blocks are mostly template blocks like Post Title but also include unrelated things like Query variations. The “Design” category has unfortunately become a bit of a dumping ground that contains a number of unrelated blocks like Site Title, Post Tags, Columns, and Buttons).

The “Widgets” category is where block-based versions of legacy widgets live. Since “widgets” is a paradigm that will phase out over time (widgets are really just blocks like any other) this category doesn’t make much sense except as an interim. Especially as the blocks themselves can be quite varied, E.G: Search, Posts List, Shortcode, RSS.

Finally there is a large “Embeds” category which is where blocks that enable you to display third party media live.

Card sorting

The first thing I wanted to do in this exploration was identify which blocks belong only in the post editor, those which belong only in the template editor, and those which are truly global. Once I’d identified this I was able to begin thinking about potential categories within those contexts.

To do this I embarked on a card sorting exercise in FigJam:

Here’s a summary of my observations and organisational changes:

• A surprising number of blocks were consolidated in to several categories within the template editing context.
• There are way more template-only blocks than post-only blocks.
• Embeds and Media have essentially been combined.
• Several widgets moved to an “Internal links” category. I’m not sure what the best name for this is, but most of these blocks focussed on linking to other areas of the site e.g. tag clouds, category links, recent comments, etc.
• The “Design” category was split into more contextual compartments; “Layout”, “Internal post navigation” (more link, page break), and Feeds.
• A number of sections could potentially be de-emphasised in the UI. All the meat exists in Text, Media, and Layout.

Design Prototype

Although I only added one category overall (in the post editing context) one thing that struck me was how broad the block library really is. And this is just when you observe core blocks, an established site may have many more blocks installed via plugins and the block directory.

This got me wondering whether presenting a wall-of-blocks in the Inserter is really the best approach, or whether it might be better to encourage searching, and only list frequently used blocks for quick insertion.

A quick design mockup piqued my interest. I figured we could allow folks to customise how many “Frequently used” blocks to display, and provide access to each of the block categories using the same drilldown pattern as the latest Global Styles designs.

My hope is that this would make the Inserter less overwhelming, and feel more intuitive to use for common tasks.

To try this idea out I made a CodePen prototype and quickly noticed that the drilldown pattern could even be used to expose patterns relating to specific blocks upon insertion.

There’s still some work to be done here. For example I’m not sure how the tabs might interact with this design… the “Reusable” tab feels like it could just be a category within the inserter. And if we’re exposing contextual patterns upon insertion, maybe that tab is superfluous as well?

Where the heck should the Buttons block live?

Scalability is also top of mind, do these categories provide a framework that block authors can intuitively plug into without having to create their own sections?

Finally I need to mockup a version of this for the template editor, which will include a significantly larger catalog of blocks. Maybe the sky falls down in that context.

These are all explorations for another day. For now, feel free to mess around with the prototype here, and as always, do not look at the code 🙂

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.