Expanding template creation options in the Site Editor

There is a short list of theme templates that users are able to create on demand in the Site Editor. Off the top of my head that list is something like:

  • Front page
  • Search
  • Single
  • Page
  • 404
  • Archive

The WordPress template hierarchy allows for much more expression than this though, and one of the objectives for 6.0 is to unlock some of that functionality in the UI.

The WordPress template hierarchy in all it’s glory

It’s a tricky interface to design because we have to tackle concepts that I suspect folks contemplate in a subjective manner. For example how do you imagine the sequence for adding a unique template for your “About” page? I can see at least two lines of thought:

  1. I want to create a template for a page, so I’ll look for the pages section, and expect to find my “About” page within that section
  2. I want to create a template for this unique piece of content, so I’ll look for something that enables me to search my whole site

I decided to roughly explore a prototype for each approach. The first makes use of a dedicated “Page” section in the template creation UI where folks would find the primary Page template supplemented by a search input to locate a particular page:

The second prototype presents a single UI for creating specific templates for any use case, not just pages:

A benefit of this second approach is that the primary templates like “Page”, “Post”, “Attachment”, and so on require fewer clicks to create, and those flows feel simpler since you do not need to ponder the specificity angle.

The drawback is that the full specificity gamut is exposed in one UI. As you can see in the video results will include pages, posts, categories, tags, authors… everything. To avoid this being overwhelming some kind of filtering may need to be introduced.


For now these are early concepts and I’m still exploring other potential flows. I’ll likely post these (or some variation of them) in #37407 soon. Feel free to follow along!

Exploring a global UI region in the Site Editor

In addition to features like Reusable Blocks a number of other global concepts emerge in the Site Editor:

  • Navigation management
  • Template management
  • Styles
  • Site settings

And yet we lack a centralised area in the UI in which to manage these things. Consequently there is a lack of clarity with regards to whether a setting is local or not. For example Global Styles appears on the same plane as block settings.

As a part of #36667 I’ve been ideating on high level design options to improve this. In particular I’m drawn to a left-hand panel with an inverted color scheme as a home for features that are global in scope. The icon column is a common design pattern for adding layers of navigation that we see in software like Slack and VSCode.

One reason I’m particularly excited about this concept is that it provides an intuitive way to navigate to (and edit) your posts / pages in the site editor, something that as yet has proven tricky to get right.

A subsequent idea emerges that in the far future it could be possible to manage posts and all manner of other WordPress functionality here:

Until then, this feels like a promising idea for the Site Editor. Follow along in #36667.

Concept: Creating a query builder inspired by design tools

Design Tools and their associated UI are an exciting development both in terms of the power and flexibility they will afford users, but also how they will replace chaos with consistency in the block editor UX.

I think the design does a really good job of tidying complex features / interfaces away until the user actually needs them. Not all blocks need padding, but it should be easy to add it as desired. The overall experience feels much less cluttered.

This got me thinking about one of the most complex block we have – the base Query Loop. Could we use this same design pattern to make an intuitive UI for query building? I couldn’t resist putting a quick prototype together…

The idea here is simple, when you insert a Query Loop it will display everything from a single post type (multiple post types doesn’t make much sense to me). You then add and combine filters using the familiar Design Tools UI until you’re satisfied with the output. I think this does a good job of avoiding the currently overwhelming experience when interacting with the vast multitude of options this block offers.

This pattern could not only be used to toggle filters on the Query block… maybe it’s also possible to toggle panels like Typography, Dimensions, and Border on all blocks.

Refining the Posts List block

For those not familiar with how WordPress works under the hood, The Query block (and its friends Query Loop and Query Pagination) can be tricky to understand. Attaining this knowledge shouldn’t really be a requirement to do something simple like display some posts from a category on a page that you’re creating.

The existing Posts List block helps with discovery, but upon insertion users are still faced with the Query and it’s associated complexities:

Taking the Posts List block for a spin

The experience is especially bad at the moment, because options like “inherit query from URL” are practically useless in the context of editing a post or page, and Query Pagination doesn’t work at all.

Today I explored how we might extend the Posts List variation so that it feels more like a unique block that stands by itself, and obfuscates some of the complexity of the underlying Query. The concepts are described in the video below:

An optimised version of the Posts block

Summary of changes

Here’s what changed:

  • “Posts List” renamed simply to “Posts”
  • Query Loop block is hidden in the UI
  • Post type selector is removed
  • “Offset” and “Include sticky posts” options moved to “Advanced” panel
  • Confusing “inherit query from URL” setting is hidden
  • Filtering options tidied up
  • Layout and ordering options tidied up (icons need some attention)

This is my first take on this block, so changes will no doubt be forthcoming. You can follow along on https://github.com/WordPress/gutenberg/issues/32268