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.
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:
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:
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)
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.
This one is proving rather tricky to get right! Feedback on previousiterations from the Full Site Editing Go / No Go discussion that took place this week indicates that seeing the pattern carousel on the canvas can be problematic.
It’s beginning to feel like one of those situations where a little friction in the UX can actually be quite helpful in helping the user to pause for a moment, and take in what is happening.
For linear end-to-end flows like this I often find that modals work well as they help establish the focus that is necessary to complete the task. So here’s a take on the pattern selection UI built in to a modal:
This modal would be triggered on mouse-up to account for blocks being dragged from the inserter on to the canvas.
A nice thing about encapsulating this flow in a modal is that it can be entirely consistent regardless of entry point. This virtue could be valuable since there are many circumstances in which a user might find themselves inserting a block pattern; creating a template from scratch, transforming a block, editing a template part, and so on.
An idea Joen and I have discussed a lot recently is providing users with a way to zoom out a level from the thing they’re editing in order to make more sweeping changes to the composition of their document.
This affordance can be a very useful tool when working with something like a template, where you might want to move a block over longer distances.
The notion of zooming out and revealing more of the “canvas” also creates an opportunity to introduce other features that perhaps do not fit in (or work so well) in the regular view. Pattern suggestion springs to mind as an obvious candidate.
A new Mode?
One way to add this feature to the Site Editor would be through a new Mode. Accessible through the menu in the top bar, or via an individual block’s toolbar, it would put these powerful features at a users fingertips in a variety of common flows.
Here’s a quick video mockup to demonstrate.
As the new Mode is engaged a number of changes occur:
Root level blocks are reduced in size, spaced out, and their Toolbars are hidden.
These blocks can be clicked to return to edit mode, or – if dragged – easily moved around the document.
When a block is selected in this mode, any contextual block patterns are exposed via a carousel.
Children of root level blocks are locked and cannot be manipulated.
Clearly there is a lot of work still to do here, but I think it’s an exciting concept because despite being such a powerful feature, it could be relatively straight-forward to implement in a piecemeal fashion.
Perhaps the initial iteration is only accessible while editing templates. Subsequent iterations can include pattern discovery for template parts, and then other block types. Finally the Mode can be introduced to the post editor as well.