Beyond the canvas – continued exploration in site management interfaces

Last month I shared some concepts where “global” site elements could be managed in a dedicated area of the UI. In this post I’m expanding and refining those ideas a bit in an effort to explore the broader viability.

If global entities like styles, templates, and navigation menus can be edited in the Site Editor, then it seems feasible that folks may want to manage other parts of their site there as well.

The Site Editor was designed mostly to handle presentational things like posts, styles, and templates, but non-visual entities like users or settings need further consideration. Along with general content management, these are the kinds of things that I concentrated on here.

During these explorations two key UX requirements emerged:

  1. When a management view corresponds with something that could be edited visually, a direct and intuitive pathway between editing and managing should exist
  2. Since the lines between managing and editing can sometimes blur in the site editing context, a distinct visual language should help users orient themselves in the experience.

As is often the case with these things, pictures speak louder than words, so here’s a quick demonstration of how I envisaged a user zooming out of the editing experience to find access to management areas:

The (W) button in the Editor acts as a pathway to the relevant management view. The dark colorisation of the button creates a visual hint towards the nature of the destination and helps to conceptually separate management and editing. Clicking the preview window takes you back into the Editor.

This pattern and design language satisfy the two points outlined above.

Is it a template? Is it a category? No, it… doesn’t matter

As yet we’ve not come up with any elegant pathways to edit entities where content and template overlap.

For example the “Posts page” in WordPress is presented (somewhat misleadingly) as a “page” in the backend, but always redirects to a specific template (not the page template, notably) when viewed on the frontend.

Similarly things like post categories have a content element – you can add a custom description – but right now you can only edit the archive template agnostically. It should be possible for folks to edit and create templates for specific categories without having to understand the technical cruft going on beneath the surface.

We can use the pattern above to contextually surface previews (and therefore editing access) on the relevant screens. As an example, here’s how I might edit a post category:

From this management view it is possible to invoke an instance of the Editor where you can customise the relevant content and template simultaneously. In this environment you might also be able to create a new dedicated template for this particular category.

The Finder-inspired columnar navigation creates the hierarchy of the drilldown pattern we explored in the past, while still providing direct access to the top levels of navigation – something the original drilldown lacked. If this feels like too many columns, tabs could be used for filtering instead, and the primary navigation could collapse down to icons as you navigate deeper in to a section:

But this doesn’t scale down quite as well to mobile devices. At this point it’s worth repeating that these are all very rough concepts…

Still, they hold up quite well in other areas of site management, and feel aligned with the idea of WordPress being an operating system for the web.


Making quick edits to media meta is easy to imagine, and this pattern would translate well to other management areas. I can see a lot of value in being able to update things like publish dates, authors, titles, and so on, without launching the “full” editor.

This hybrid management / preview screen is extremely useful when working with particularly complex menus that include lots of nesting.

Such menus get very tricky to directly manipulate on the canvas, but you can always click the preview to zoom in and do so if desired.

Templates, Styles, and settings

The template management above view is simply a dark-styled interpretation of the one we’ve already implemented for 5.9. A toggle to view the templates in a mosaic configuration (using the preview component) would be a nice enhancement that continues to build on the zooming metaphor.

Likewise, Styles use the same panel that is shipping in 5.9. A mosaic of curated templates in the preview area could provide holistic feedback on style adjustments.

Visual settings like the site icon need to live in the Site editor. Options such as front page settings are also integral to the site editing experience. Folks shouldn’t have to go all the way back to wp-admin to do this. Once again the preview area adds value by clarifying the visual component of these options.

I’m not sure what the next step is here, but I’m hopeful to see some of these items worked on for 6.0. #36667 and #37001 seem like good candidates to explore further.

Is the writing is on the wall for the WordPress theme as we know it?

The essence of a WordPress theme is: layout (templates) + style = presentation. 

The template and global style editing features of the site editor are soon going to provide users with tools to create and manage these elements visually in their WordPress back-end. Community initiatives like the pattern directory present opportunities to enrich these features exponentially.

So the question emerges: If I have the power to tailor the individual components that make up a “theme”, supplemented by curated suggestions from the community while doing so, then what purpose does a single bundle of predefined layouts and styles serve? 

I imagine a world where the idea of themes being discrete entities that you install and switch between goes away. Instead, the “default theme” in WordPress is nothing more than a generic version of the templates and styles necessary for the most basic site to operate.

On top of this, flows exist in the UI that enable users to perform bespoke activities, like creating a different layout for a specific post category archive.

In such a flow the user would be presented with contextual layout options that are pulled in directly from the pattern directory. Oh, you want to create a new 404 template? Here are dozens of neat options to choose from, ordered by popularity, rating, you name it. This feels much more powerful than having to accept whatever your theme supplies – especially as it’s unlikely that you chose your theme because of it’s 404 template!

Styles can work in a similar way. Imagine selecting an appealing color palette from a community driven library, directly in the Styles panel of the Editor, and having that cascade across your entire site. Ditto for typography. These tools can all combine in flexible ways to get you 90% of the way toward your desired design destination. 

Naturally you can fine tune everything on a per-block basis as required, and even choose to contribute your creations back to the color, type, or layout directories, further enriching those libraries.

On that note, maybe new economies begin to emerge – imagine paying a small tip to install a comprehensive type scheme devised by some A-list design studio. An App Store for style?

No doubt it would still be possible to export your templates and color / type styles as a single theme bundle. But in a world where folks have freedom of expression on a much more granular level, I wonder about the utility of such a package.

When you’re able to easily apply different aspects of design to a single post, a single template, a site header, or even a single block, the concept of a “theme” starts to feel much less monolithic. I’m excited to watch these features interact as they grow and evolve.

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.

Contextual editing clarity

One of the most challenging elements to get right in the site editing UX is where and how we draw lines between the different editing contexts.

Until now, no lines have been drawn at all. In both the Site Editor and the Template Editor, if you’re able to see content, you can edit it directly, free of any friction whatsoever. Of course there are benefits to this – direct manipulation is a compelling argument. But as documents become more complex, and template editing more prevalent, drawbacks emerge.

In the go/no go discussion (re FSE in 5.8) last month the Query block came under scrutiny:

I think, also, to be honest, this is a bit too powerful right now. You can essentially modify any of your post’s actual content, feature images, and so on. This should probably not be the default. It should probably be something that you have, like, one more step to get there.

Matías Ventura

The same argument can be made in regards to template editing. Being able to edit the content of a post while also editing the post template blurs the lines between these two very different exercises, and undermines the very existence of separate content and template editors in the first place.

The issue is compounded when you consider the query block. Imagine inserting a Query in a page, then navigating to edit the Page template. Suddenly it’s possible not only to edit the content of every single post on your site in the context of a template editing session, but also to mistakenly drop that query in to the page template itself and potentially break the appearance of your whole site. Similar problems will surface when it becomes possible to edit templates for archives and search results.

You may argue that an experienced user would not make these kind of mistakes, and for the most part I agree. But with the template editing UI coming to 5.8 it will not only be experienced users who have access to this powerful feature.

It is my opinion that we should test some prototypes that add friction to content editing exercises that are outside the context of the current exercise. That is to say: if I open a page and engage the template editor, I should not be able to directly manipulate the content of that page. Likewise, when I insert a query in a post, I should not be able to directly manipulate the content therein.

You can probably guess what is coming at this point… 🙂 Yesterday I opened a draft pull request that serves as a proof of concept. It is very rough, but with some css hackery I was able to spoof making post block content un-editable in the template editor. Here’s a video:

Blocks like the Post Title, Post Content, Post Date etc can be selected, and their attributes can be modified. But their actual content is gated by an overlay UI similar to the one we’re exploring for template parts and reusable blocks.

It doesn’t feature in the PR, but it is quite easy to imagine some simple interactions that “unlock” edit-ability of the content. It might be a double-click, a keyboard modifier, a lock icon in the block toolbar, or a combination thereof.

The objective here is primarily to establish clear definition between content editing and template editing. I’m increasingly of the opinion that this will be a critical pillar of the UX if we’re to pursue dedicated views for these different editing contexts.

Try the WordPress navigation of tomorrow, today

Since 2018 I’ve been pushing to design and implement a new navigation system that scales in the WooCommerce Admin project.

It seemed important to me that for the project to be a success it would have to be a core-first initiative, at least at a grass-roots level initially. I’ve worked through various iterations (some of which were shared on this blog in back in 2019) that considered not only the WooCommerce scope, but the entire WordPress ecosystem.

After some usability testing of our most promising concept in 2020 the team made the commitment to build the components required to realise the vision, and contribute them back to WordPress (Gutenberg specifically).

That new navigation system is currently being rolled out to eCommerce plan customers on, with positive results so far. It will eventually make its way in to WooCommerce core.

Gutenberg itself now uses those components for navigation in the Site Editor as well.

And now it seems the broader community are beginning to play with the idea of using this new component set to replace the existing wp-admin navigation as well.

It brings an unironic tear to my eye to see this plugin Ryan Mccue has put together.

It seems like such a small thing, but this is the result of years of on-and-off work for me.

I’m not getting carried away yet though, it could be years before something like this finds its way in to wp-admin. And yet I remain optimistic. Rome wasn’t built in a day, and all that.