Between clouds and mud

If there’s one thing I’ve learned during the last year or so working on WordPress core it’s this: it is very difficult for fast-moving open source community projects that live almost entirely on code-centric platforms to be led by design.

I kind of knew this from when I was more focussed on WooCommerce. But the difference with WordPress is that we do not own the project, so it’s not possible to make decisions unilaterally – the community must be involved every step along the way.

Workflows mostly revolve around reported issues on github, so solutions are reactive, and tend to be narrowly focussed and technically motivated. This feels like an inevitable progression because reviewing and benchmarking code is generally easier than judging design. It is clear whether a code submission is an enhancement or not, so the community is able to find consensus relatively quickly. Design is less binary, and more subjective. (This is a little hyperbolic, but hopefully you get the point).

My colleague David Levin has a funny metaphor for describing how it feels to work in this environment as a designer:

“Sometimes it feels like you’re trying to design the plane while it’s already in flight”. 

As someone who often finds himself drawn to macro UX design, I like to find solutions that can be applied canonically to several related issues… basically the DRY principle applied to design. Consequently, I will end up sharing the same principle across multiple siloed conversations, which can be exhausting.

But without that exhausting repetition we risk implementing different UI patterns that all accomplish roughly the same thing, to the detriment of the overall end user experience. Not to mention the bloat added to the design system.

Continuing the plane metaphor – an aircraft with jets on one wing and propellors on the other may still fly, but it won’t as easy to pilot as an all-jet or all-prop configuration.

To the annoyance of Shaun Andrews who coined the term, our team affectionately refers to this challenge of high-level thinking and low-level acting as “clouds and mud”. It sounds cliché, but it summarises the mental exercises designers working in this space have to do.

Innovate in the clouds

“If I had asked people what they wanted, they would have said faster horses.”

The alleged Henry Ford quote is extreme, but there is a grain of wisdom there, I think. It can be difficult to truly innovate when the status quo is reactive, microscopic problem solving. It’s all too easy to get distracted by the worms and the weeds.

Perhaps we can entertain something between these two extremes? A “first principles thinking” process whereby related issues are grouped and examined together in order to explore holistic design solutions for the root problem, thereby solving the group through extrapolation.

Stepping even further back perhaps new features should not be built at all, until there is consensus around a documented design vision? These visions should be explored in the clouds, where we have a bigger field of view and more freedom of movement and expression.

Reflecting on the last year, this has been the biggest challenge for me. This week I begin a three month Sabbatical and I hope that time out of the trenches will enable me to find some actionable ideas around topic.

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 –

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.


  • 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.

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

Ideating on template part flows

The Template Part block existing in the Site Editor isn’t much more than a proof of concept right now. The recent addition of the area taxonomy has enabled us to present semantic variations for things like headers and footers, but many key flows remain ripe for design optimisation. This week I shared some ideas on how we might make improvements to the template part block in Gutenberg.


Creating something like a site header is currently a rather arduous process. You must:

  1. Insert the Template Part block
  2. Click “Create new template part” button
  3. Assemble inner blocks
  4. Manually assign the template part to the appropriate area in the “Advanced” panel of the Inspector
  5. Give the template part a name

For the average user this is way too complex. With template editing functionality coming soon these concepts will be exposed to users in the Editor for the first time ever, and so a need to simplify emerges.

My first idea is to reduce the number of steps required to create something like a header, and augment the process by presenting contextual block patterns in order to help folks get started more quickly. Here’s a video demonstration:

I propose that we re-purpose the “Header” and “Footer” template part variation blocks to serve as pseudo wizards. In doing so we can replace steps 2-4 from above and deliver the following flow:

  1. Insert “New Header” block
  2. Select a block pattern

In this case we know the user is creating a header so the area can be assigned behind the scenes. Likewise we can automatically apply a more useful name based on this context and ask the user if they’d like to add a custom name after-the-fact.

A “Start blank” affordance is offered in case no suitable block patterns match the needs of the user.

The pattern carousel that appears in the modal is a reused component. The same UX is presented to users when getting started with something like the Query block.


The process to insert an existing template part is also rather tiresome. Imagine you wanted to insert your “Standard Header” template part in a new page template, right now you have to:

  1. Insert the Template Part block
  2. Click “Choose existing”
  3. Find the template part and insert it

Not only is this flow longer than it needs to be, it also relies on users understanding the technical relationship between template parts and their taxonomic areas. I can’t imagine that many folks looking to insert a site header would expect to do so via the abstract “Template Part” block unless they’re already familiar with WordPress theming paradigms.

The solution here seems fairly simple – expose all published template parts in the various inserters. Here’s a diagram:

Published template parts can be inserted directly in a single click

This makes the blocks easier to understand based on how they appear in the inserter (categorised and supplemented by the icon) which will be particularly important when viewing search results.


One benefit of semantically related template parts is that it enables us to provide a handy swapping mechanism so that users can interchange same-kind layout areas on-the-fly. A the moment this is accessed through the “Replace” button in the template part block toolbar:

Swapping a template part

I think it’s fair to say that we can make some refinements here!

First of all there is a question to be answered around how useful search will be in this flow. It seems unlikely to me that a site would have so many headers that a search would be required to find the right one. You may argue that there may be enough generic template parts and I would agree with you, but I would also say that it seems unlikely that one would ever need to swap one generic template part for another. Swapping only really seems useful when semantic context is present.

I love reusing flows and components wherever possible, and see no reason not to reuse the modal from before in this flow as well. When you elect to replace a template part, its relatives can be displayed in a modal like so:

The diagram above demonstrates the “Grid” view rather than the “Carousel” view from the video above. Both views will have their merits based on screen size, the particular template part being swapped, and so on. By reusing this component we get access to that affordance “for free”.

That’s it for now! This is all very much a work in progress, and you can follow along with progress in this tracking issue on github.

Refining template flows in the post editor

Template exercises in relation to a single post are accessed through the following interface(s):

In #31591 I outlined some of the issues with this initial UI implementation, and opportunities to enhance the overall UX:

For block templates, the experience can be enhanced with visual previews of the templates. Since this is the future, we can embrace it.

This UI lacks hierarchy. Changing templates will likely be the most common activity so this interface should be most prominent.

The “Create a custom template” modal could elaborate more on what templates are

When there are many templates, a search can be useful

When the default template is selected, it is duplicated in the template list

Consolidate the “Back” button (to move from editing the template back to the post) in to the top bar

I presented the following design solutions:

Changing a template

Editing a template

Creating a new template

There will be some debate about whether access to these flows should exist in the Inspector (sidebar) or the top bar. In the long term I expect them to reside in the top bar, but the Inspector may serve as a transitional home for them. The UI has been designed in such a way that it can sit in either location with equal comfiness.