Want to get involved? See the handbook and optionally drop into #design to chat. Most active design work happens in the block editor project, consider dropping into Needs design or Needs design feedback.
There’s a WordPress Component Library in Figma. Duplicate to edit, direct access is reserved for the design team.
Over time the number of appearance and accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) options in the Editor has grown, and is likely to continue to do so with new features continually in the works.
To create an editing experience that feels intuitive, folks will often need to tailor these settings based on their individual preferences and needs. There is no such thing as a one-size-fits-all.
Instead of relying on people to find these settings on their own (admittedly they’re a little scattered, but that’s another issue), it might be good to surface them during onboarding. Consequently, users can set up a comfy editing experience straight-away.
In this post I’m sharing one idea to accomplish this, which essentially augments the current welcome guide in order to expose these options.
If you aren’t familiar, the existing welcome guide outlines several features of the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor over 4 different ‘slides’ presented in a modal:
The first part of this design exploration condenses those slides into a single, larger one. Here is a demonstration of how we might do this:
It would be good to explore more opinionated designs / layouts for this slide, and consider how we might optimise the copy. This is just one option to get the conversation started.
The primary call-to-action encourages the user to configure the editor, but there’s a secondary option to skip configuration and simply ‘start writing’.
The configuration process consists of three steps, each of which include options that fit into a particular theme.
The first step offers a way to set up the Document Toolbar display. Hovering or focusing on each radio button will cause its effect to be rendered in the preview on the right-hand side of the modal.
Note: This option isn’t implemented just yet, so may not be necessary immediately.
In the second step we find options relating to the block toolbar. As before, hovering/focusing a radio button will cause the preview area to render the corresponding effect. As there are two options in this step, the user effectively gets to observe how they both interact at the same time which will really help illustrate what the finished configuration will look like.
The text formatting option is another one that hasn’t been fully implemented yet, but it exists in the codebase and is ready to go.
The final step follows the format of the previous two and contains features pertaining to accessibility.
Once all options have been selected, clicking ‘Finish’ will exit the set up process and the user will be dropped into the freshly configured editor.
Here’s a short video demonstrating the entire flow:
First and foremost, it would be good to gather thoughts around whether this is a good idea in the first place. Secondly, how does everyone feel about the options presented in the media above? The three steps were informed by the available options, so if we were to consider others then the steps might need to be tweaked a bit. Perhaps there are alternative ways to categorise the features presented here?
Over to you!
You must be logged in to post a comment.