Re-organising the block inserter

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.

“Frequently used” blocks are front-and-center

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.

Drilling in to a category gives the blocks within room to breathe

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 🙂

Exploring information architecture in the site editor

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:

Opening the Site Editor reveals a dedicated content management home screen

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
Content overview on mobile

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.

The three pillars of content management: Overview, Edit, Bulk manage

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 (W) 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.

Editing global content via the Query block

Live editing post data inside a Query block – whilst editing something else like a page – requires some demanding mental gymnastics in terms of the UX. Users are required to understand that editing block properties (like position and alignment) are local to the page, while any data changes (like updating the publish date or the post title) are global. None of this is made very clear in the current experience as you are able to fluidly perform either action.

Me – https://github.com/WordPress/gutenberg/issues/32317

Today I explored a solution that adds a layer of friction between editing two global entities within the same view. There’s nothing really new here, I’m essentially building upon a concept I’ve shared before for the template editor. The use case is virtually identical.

Notes

  • Clicking anywhere on the Query will select it
  • Only when the Query has been selected can you interact with its children
  • Selected children exhibit some unique characteristics:
    • A semi-transparent overlay indicates that the block contents cannot be edited directly
    • Other blocks of the same type in the Query are highlighted with a dashed outline
    • The parent container exhibits a dotted outline
    • Content editing is accessed via:
      1. Click the more menu in the toolbar and select the “Edit” option
      2. Click the lock icon in List view
      3. Double-clicking the block
    • While a child block contents are being edited the following visual treatments are used to indicate it is a separate entity
      • Other blocks outside of the scope of that post are dimmed significantly
      • The post itself displays the isHiglighted treatment
      • The document title in the top bar is updated. This is based on the notion of displaying the document title in the top bar (#27093) and the existing pattern in the template editor of moving back to a referring entity.

There is quite a lot of redundancy built in to this concept, and some of it may be overkill. For now I’m throwing everything at the wall to see what sticks. Perhaps we can exercise some subtraction as we separated the wheat from the chaff.

Enhancing the Add Template flow in the Site Editor

The current experience is a little lacklustre. After clicking the + icon you see a list of options with verbose descriptions.

The current Add Template flow in all its glory

Gutenberg affords us the opportunity to make this a more visual experience. Especially when we factor block patterns in to the equation.

The nice thing about this design is that we can apply it to content creation flows as well. Here’s a rough idea of what adding a page could look like:

Discussion (and much more detail) can be found in issue #29558.

i2: On-canvas transition between content and template editing

The idea here is to display all block controls while editing content, but apply some kind of “disabled” visual treatment to them. Adjusting the opacity is probably easiest, but there are most likely other options to explore as this may not be accessible enough (color contrast). I’m keen to get the flow right initially and focus on these finer details later.

You can navigate directly to the template via the ellipsis menu on the block.

Alternatively, clicking any “disabled” control will open a dialog asking the user if they’d like to edit the template, and briefly reminding them of the implications of doing so.

The transition to template editing view is made clear via the UI changes proposed in #27849 (IE the inverted top bar). Let’s not dwell on that in this issue.

In template editing view the previously “disabled” controls are now enabled and you can make any changes you need to. However, the contents of the block (“Hello World!”) is locked since we are now editing the template. To get back to editing the content you can click the “← Return to post” link, or simply double click on the text.

Any changes to either the post or the template will be surfaced in the multi-entity save flow.


More discussion here.