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.
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.
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.
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.
Site editor tasks typically vary from post editor tasks. Instead of the freeform writing that occurs when one is drafting a post, it more likely to find yourself traversing different areas and different layers of the document when making adjustments to a template.
Over the last few weeks we’ve been experimenting with ways to make those site editing exercises feel more intuitive. In large part this has been founded on the idea of displaying various outline states as you hover and select blocks on the canvas. These combine to instill confidence when selecting and working with more complex nesting, and container blocks like Template Parts.
It’s not perfect yet, but I think the outline effects are a net positive as demonstrated in the gif above.
The enhancements we’ve added to Edit mode in the site editor have effectively resulted in it consuming several of the characteristics of the pre-existing Select mode. This is problematic because it brings the very existence of a dedicated Select mode in to question, and creates inconsistent UX between the post editor and the site editor. How can we address this?
The most sensible way is to holistically transplant the outlines we added to Edit mode in the site editor, to Select mode. This will result in a consistent experience as folks switch between modes in both post and site editors. An added benefit is that we inherit the click-through behaviour we’ve been wanting to explore for template parts and reusable blocks for free, since that is already built in to Select mode.
As discussed above, site editing is a less linear exercise than post editing, so it also makes sense for Select mode to be the default mode for the site editor. This works well in rudimentary terms, but Select mode is still missing some key features, namely:
Upon block selection Edit mode is engaged instantly, and there is no way back to Select mode without actively initiating it via the icon in the top bar.
This essentially means that after you’ve selected and begun editing a block, selecting the next block to edit becomes a tedious task, aimlessly clicking around the visible space the block occupies hoping against the odds that you are able to select it. We need an elegant way back to Select mode.
Intuitive selection of an object to edit is one of the most crucial interactions to get right in the site editor. I don’t believe we should be relying on people manually switching modes. We can do better!
In the last couple of days I’ve been playing with a prototype (it’s rough – don’t try it on mobile and under no circumstances look at the code 🙈) that addresses the issues in Select mode, and makes the transition between Select/Edit modes feel more seamless. The following heuristics are implemented:
Select is the default mode.
Hovering a block displays a strong outline – this is helpful for container blocks like the Header in the prototype.
Clicking a block will select it, revealing the block name.
Clicking a child block (like the Site Title in the prototype) will select the parent first.
When a parent block is selected, its immediate descendants become interactive.
Clicking a selected block engages edit mode. If the selected block has a parent, it is indicated with a dotted outline.
With edit mode engaged, clicking anywhere outside the selected block deselects it and returns you to Select mode, unless…
You click on a block of related context – in this case edit mode is retained. This is demonstrated in the prototype by moving directly between editing the Site Title (a text block) and the Paragraph (also a text block).
The video below illustrates each of these behaviours in turn:
In addition to the icon in the top bar, the outlines (or lack-thereof, mode depending) help indicate which mode you are currently in. Edit mode is clean and simple, with less visual noise. Select mode adds the necessary UI to enable block selection and manipulation.
You’ll also notice that the block movers are only visible in Select mode. I think it might be interesting to make this mode about selection and layout primarily, and let Edit mode focus on the block contents and attributes. But that is a discussion for another day.
We have a PR open here to set Select as the default mode in the site editor. If this idea gains traction development will likely take place there.
Today I shared an exploration on how we might enable users to configure the home / posts page settings while editing a page. It was a long one, so for the full details I refer you to the comment on github.
In short, the complexities associated with these simple-looking settings are quite vast. The home and posts pages not only have interactions with one another, but there is the front-page and home template to factor in as well.
Cognisant not only of those complexities, but also the fact that the canvas may need to radically update to reflect changes to the settings, the simplest way to enable folks to manipulate them is via modal. Here’s how I might set the page I am currently editing as my home page:
And here is how I might change which page is set as the home page, whilst editing the front-page template:
For a final bonus point, while editing the front-page template, here’s how things unfold if I set my homepage to display my latest posts. This is a good demonstration of how the canvas needs to be updated to reflect the settings.