This Post is a written version of the Presentation I gave at WordCamp Europe 2021.
There are two aspects that we will be focussing on:
- Who are we optimizing for and what do they value most?
- What can we do across the board to improve the experience?
The goal we should be setting for ourselves is that the editor steps into the background and our user can just focus on the content that they are trying to share.
We are going to look at how we can achieve that goal from three different angles.
- How we can define who we are optimizing for.
- Shared principals we can use to improve blocks.
- What role Themes play in optimizing the editorial experience.
Good editorial experience means something different to different people.
What one person might consider freeing flexibility is another’s person nightmare of complexity.
Therefore we have to know who we are building and optimizing our user experience for.
In most of the work I am doing, and therefore what my point of view is biased towards, is building editorial experiences for client sites that have strong defined design systems. In that context it becomes much more important to have consistent elements that are shared across a team of editors. The goal these editors have is to share their information without needing to worry too much how individual elements look. That was pre determined and they now just use these building blocks to give structure to their content.
While this approach may be a great user experience for that group, another group may value really being able to adjust every single detail like border radius, column width or button color.
Based on what type of user experience we are aiming for there are different approaches of delivering on the goal of an editor that gets out of the way.
If we look at this Call to Action design for example. There are several approaches of how we can represent this content in the editor.
When planing how to convert this design into a block the requirements we come up with may look something like this:
- A field where the editor can enter the content on the left
- A field where they can enter the Call to Action text
- A field to chose where the CTA should link to.
If we take these requirements at face value this is what we end up with.
And in theory it meets all those requirements. Editors can provide the content they want to share and thats it. However it fails at the goal we initially defined. The editor has no idea of what that content will actually look like to the end user.
Ive seen it before where the solution to bridge that gap was adding a button in the toolbar that allows editors to toggle between the editing experience and a preview of the block. Or moving the editable fields to the block sidebar and using the content area to render a preview.
These approaches come with problems though. An editor first needs to learn where, how and even what they can edit. And that knowledge does not transfer well to other blocks because they might do it differently. And there is a lot of back and fourth context switching that editors have to do. They can never just focus on the content they were trying to share in the first place.
By slightly changing the way we look at this problem we can actually solve for both of the goals we defined. Instead of trying to pull out the items that we need to make editable we can should make them editable inline.
And this is where my earlier point about different definitions of a great user experience for different audiences comes into play. This is the point where we need to decide wether our target audience of editors values consistency over flexibility or wether they really want the ability to build everything from scratch in the way they want.
In the case where we are optimizing for consistency we can build a custom block that uses the RichText component to make the portions of the markup we need to make adjustable editable.
We as the designer and developer have control over how a call to action should be represented and the editor can use that wherever they want. The options the have are limited to editing the content and whatever options we want to provide them with.
If on the other hand we are optimizing for flexibility this can also be build using core blocks. And to make it easier for editors we can register a block pattern for it.
The pattern looks exactly like the design when inserted and can also be used anywhere. But it also allows the editors to modify everything to their liking.
If they want to move the button around to now be on the right or have two buttons stacked on top of another it literally just uses a group, columns paragraph and button blocks.
So these building blocks can get rearranged to build whatever the editor wants. But keeping in mind that with great power comes great responsibility.
Having all the options means that editors can make “bad” choices, or at least choices that may not align with the overall design language / aesthetic of the rest of the page.
Taking a step back from this specific example here.
I am not saying that in version two where we are optimizing for flexibility we don’t need or even shouldn’t build custom blocks.
But the blocks that we build are more atomic elements that can get used in combination with other blocks to build whatever the user wants.
While in version one we may build more complete “molecules” to steal from the atomic design verbiage.
Principals for building blocks
Now that we have talked about the fact that there are different audiences we can optimize for, we can look at some principals for building blocks that apply across the board. Starting with the anatomy of a block.
The main content area of the block is the most important part that we need to consider. All common options should be accessible without needing to open the sidebar.
The principal here direct manipulation of the content.
Secondary block controls should live in the Blocks toolbar. That way they are still accessible directly without needing to look over to the sidebar.
There has been a great incentive in Gutenberg recently to unify the blocks toolbars by defining a grouping structure that all blocks should adhere to.
That new structure defines the order and the grouping of individual actions in the blocks toolbar. This graphic is coming from the Block Editor Handbook on WordPress.org and does a great job of showing the structure toolbars should have.
From start to end the toolbar first shows block level controls, these are related to the overall block and not really specific to the content of the block itself.
Then if applicable meta level followed by general tools. These tools affect the overall block and for example alignment controls fall into this section.
The next section consists if inline formatting controls. They don’t affect the entire block but only the current selected text or position of our curser.
At the end there also is a group of “other” settings and then the dropdown with any additional settings that are not as commonly used.
Any controls that we also want to provide to our editors but are not key controls can be placed in the Settings Sidebar.
The goal we should aim for is that most users should not have to open the blocks sidebar at all. A block should define sensible defaults and then allow users to modify them if it makes sense. But interacting with the sidebar should not be required to using a block.
In the sidebar it also is important to group like controls together in Panels. You can see that here in the example of the Core Paragraph. We have three defined sections in the sidebar. Typography, Color Settings and Text Settings.
Also if we have settings that are really advanced that should only be used when someone really knows what they are doing we should move these settings into the Advanced section by using the `InspectorAdvancedControls` slot.
Going back to the main content editing experience there are a few things that we now need to solve for.
How do we archive the goal of having our primary controls be inline while still staying true to what the content actually looks like?
We can achieve that by thinking of our block in one of three states, initial setup, selected and passive.
The initial setup state something that we should try to use as sparking as possible. Most blocks don’t need this and it would even degrade the experience to it to them.
So in general the best approach always is to have sensible defaults to get someone up and running quickly.
But if there are actions that an editor needs to perform to get the block up and running before actually having content to edit this how we can get them started more easily.
A great example of this is the core cover block.
When the bock is first inserted the user in only presented with the controls that they need to get started. These controls get presented in a Placeholder component that displays instructions of how to get started.
The cover relies on a background being defined. And the user can choose wether they want that background to be an image or a color.
The toolbar has some of it’s options disabled and therefore focusses on the things that are important right now.
Once that initial setup step gets completed or once a block without this step gets inserted, the block enters the “selected” or “active” state.
The main content gets shown like it will get shown to the end user and all controls in the toolbar become available. There can also be additional inline options like placeholders, block appenders for inner block areas and other contextual controls.
In the example of the Cover block there is a resize handle that gets shown to easily change the height of the block.
The resize handle actually is a great example of something that used to be a setting in the sidebar. But it is a primary control of the block that most editors will need to change almost every time. So it was moved into the main content area and just gets out of the way.
The final state of a block is it’s passive state.
By that I mean the state when the block is no loner, or another block is currently selected. That state should be a 1 to 1 representation of what the end user will see when they navigate to the site.
As you can see here at the example of the Cover block the selected and passive state ideally are very very similar.
They both aim to show the editor what their content will look like. But while the active state may present inline controls, placeholders, block appenders for inner blocks, the passive state shows none of that and only renders the markup with the styles that endusers see on the site.
What role do themes play in providing great editorial experiences?
And styles actually is a great transition point to start talking about what Themes can do to optimize the editorial experience.
The responsibility of a Theme in WordPress is to control how the content will be presented. That means that a theme will style how everything will look to the end user.
But defining how things will look to the end user means that themes should also make sure that the editor reflects those styles also. The first step is to load the styles for the blocks both on the frontend and in the editor. If the blocks markup is shared between the editor and the frontend at least the individual blocks will looks as they do to the end user.
But that is not where this stops. Themes should also make sure that all text is showing the correct font, size, line height and color. That includes the representation of the page title. Themes should also make sure that the content widths and breakpoints are similar to the frontend. So if the main content area of the site has a max width, the editor should use that same width for the blocks.
The next step is getting the vertical spacing to match. If a full width group block by default has a larger space before and after on the frontend this should also be the case in the editor.
By doing all these micro optimisation of getting these details matching we give confidence to our editors so that they can feel more comfortable just editing a site in the editor without needing to constantly switch back and forth between a preview and the editor.
The core blocks and themes are great examples of how to do it right!
If you are ever looking for inspiration or want to see examples look at WordPress Core.
The core blocks and themes are great examples of how to do it right!
While the blocks may not all be the correct fit for the audience we are developing for because they may provide too much flexibility in certain places, the way in which they surface controls and let you edit content inline is a great source of inspiration for whatever you are building.
And the same goes for the core themes. Twenty Twenty-one for example comes with beautiful block patterns and really does a great job of matching styles in the editor.
Takeaways
If you take one thing from this, it is that the goal we should be aiming for is that the editor steps into the background and users can focus on the content they want to share.
The next time you are looking at implementing a design in WordPress start by asking these two questions.
Who will be using this?
And what are they trying to do?
Next Steps:
- Take a look at all the cool components in core here: https://github.com/WordPress/gutenberg/tree/trunk/packages/components/src
- Take a look at TwentyTwentyOne: https://github.com/WordPress/twentytwentyone