The reasoning for this change is that not all templates actually display the post title. So if you’re editing a post and viewing its template concurrently, it is consequently impossible to update the title.
We make use of the Top Bar in the Site Editor to display template details and actions, so this feels like a natural evolution.
This got me thinking about the editor iA, and whether we should move all document attributes to the top bar. There are a number of potential benefits to doing this:
It reduces reliance on the heavy / noisy Inspector, and reduces its scope to tertiary block controls only.
Creates a discrete, centralised location to manage document attributes, with increased real estate for more elaborate interfaces.
Increases portability of document settings. If these attributes are presented in a popover / modal, they can be accessed from any location.
Creates a more scalable environment for plugins to provide interaction with non-visual data. This is going to be vital for complex post types like those added by WooCommerce.
I think there is further justification in that one does not need to see the canvas while working with document attributes, and that design tools for blocks are a UI that users need more frequent access to.
Here’s a rough mockup to illustrate the idea:
The portability I referred to above can be useful in the mosaic view of content we may implement in the future.
This kind of quick-editing is a feature of the wp-admin list screens, and something we’ll need to create parity with in full site editing. The modal could even provide a bulk-editing environment too.
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.
As you may know, the “Global Styles” feature is coming to WordPress, and will enable users to control a variety of visual design options from their Dashboard.
I’ve been exploring what folks might see if they were to access this feature from the Appearance menu. It’s a tricky problem to solve because users need intuitive and direct access to style management from the main navigation, but the feature must also be summonable in various other contexts like editing a template or a post in a way that provides a live preview of changes. In those latter scenarios a sidebar is utilised:
When accessed from the main navigation, it seems sensible to reuse this sidebar for consistency, but this presents a question – what do we display on the “canvas”, and how do we provide a preview of style adjustments?
Since a mosaic view of templates will be required for the initial site editing release, displaying these on the styles screen could be an affective way of providing a holistic preview of style edits on-the-fly. If there are many templates, an affordance to zoom in and out for different levels of fidelity could be a neat concept to try:
Perhaps even as one zooms in to a single template, the styles sidebar could adapt to display style options for the specific blocks utilised in that template.
The nice thing about persisting with the sidebar implementation for this screen is that the UX can be replicated on other mosaic views. If in the future there are visual management screens for things like patterns and reusable blocks, one could also access global styles from there and see a contextual preview.
Obviously there is a lot still to ideate on here, but I thought this was a fun concept to share.
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.