We are about to cross the one year mark since the release of Gutenberg in WordPress 5.0. In this lapse of time there has been an explosion of blocks being created 🎊and millions more users interacting with the block editor, leading to multiple iterations, improvements, challenges, and lessons learned.

What patterns have emerged as more intuitive? Where does the current interface fall short? What’s common and what is strange when comparing different blocks among the hundreds that already exist?

Something else that was not expected at the beginning was seeing other projects outside the confines of WordPress interested in using the block editor. This poses interesting design questions. How would a Drupal version of Gutenberg look? Is there an essence there that can help us refine its foundations?

The biggest design tension the editor faces is between making blocks and their interactions clear while not distracting people when they are creating, writing, and thinking. This is a tension that means, some times, bringing a block into clear focus and, other times, letting it recede into the background. (See #16280.)

This is particularly challenging when taking into account people have different needs, preferences, and dispositions that can completely inverse what “clear” or “overwhelming” means to each person. Density of information can be helpful to some while hindering the experience of others.

In the block editor context this translates to different tradeoffs, as the more that gets added the more complexity the interface needs to orchestrate. Making writing easy can come at the expense of making other important actions more convoluted. This, however, is the fundamental usability challenge we need to wrestle with!

Over time, the interface has evolved to handle increasingly complex needs, such as nested block structures, movement, selection, breadcrumbs, navigator, outlines, and more. These have all grown organically to meet new challenges. But in trying to address them in isolation, new problems arise: elements that were not designed to be prominent suddenly become more focused.

One thing that has proven useful is exploring “modes” in more depth — of which top toolbar, focus, and navigation are good examples. There’s been immense progress around iterating and improving upon these issues with each release. (Latest is this proposal for selection modes.) However, there are other problems that reflect structural constraints and require looking deeper at the anatomy of the block in order to improve. Sometimes this requires significant investment and thinking, as was the case with the newly introduced “navigation mode”, which can then unlock new pathways. (See #17088.)

This unlocking is crucial to create an interface that can serve all users while recognizing their intrinsic differences. One of the most fundamental aspects to address there is clarity.

The Block as a Canvas

A principle that has remained true is that the block canvas is the primary interface and brings about the expectation of direct manipulation. Blocks can define multiple states, variations, and can mutate. The canvas of the block should guide users around interacting with the content. For this, the interface needs to welcome exploration and needs to be able to teach its affordances intuitively.

One of the biggest virtues of the block is that it allows to have contextual tools when you need them, avoiding having to show unrelated tools when you don’t need them.

It also provides uniformity within diversity, as learning the ingredients of the interface happens once but scales to hundreds of blocks.

Looking at the current anatomy of the block a few aspects arise:

The natural visual hierarchy shows the main interactions or functions:

• Canvas.
• Toolbar.
• Movers.
• Insertion.

(With one hidden part in the block inspector (sidebar settings), but let’s pause that one for now.)

It is apparent that the block functions already carry interface weight and spread across a few different surfaces. When considering screen readers and keyboard navigation this also means a lot of areas that the user needs to traverse to interact with a block effectively.

With so much UI it’s worth attempting to reduce the surface, bringing it to the minimum possible to strike the right balance and clarity. There are also too many shades, making outlines and elements feel crowded and making it harder to increase contrast without increasing the feeling of overwhelmingness. This can be notorious in nested contexts, like in #14935 and the cascading issues it generates. More complex blocks surface a lot of these problems more clearly: see #17544.

A Toolbar’s Tale

The Toolbar is the second most important aspect of a block. It’s a fundamental extension of the direct manipulation principle. Third-party blocks have naturally wanted to do more with the toolbar, adding new controls or expanding on previous ones. Libraries like CoBlocks, Kioken, Editor’s Kit, and a long etcetera have been pushing those boundaries. (Color tools (#16662), background tools (#16479), etc.)

This has resulted in the following challenges:

• The toolbar has grown in complexity beyond basic alignments and formatting options and needs to be able to adopt more controls, leading to the disorganized adoption of multiple patterns (icon tools, text tools, drop-downs, modals, etc).
• Narrow contexts and child blocks result in awkward placements and rough interactions.
• Certain manipulations of the block (selecting, moving, and dragging) are disconnected.
• Controls are sometimes arbitrarily placed in the advanced inspector settings. Mobile puts pressure in having directly accessible tools for block settings as editing and what is seen on screen are together. (See Explore fixed top toolbar on mobile (again) #18632 and Consider adding text-level color settings to all text blocks #15899.)
• Navigating the toolbar, in-and-out and within its tools, is becoming more and more paramount. (See Toolbar elements are tabbable #15331 and the work in Components: Add accessible Toolbar #18534 - Components: Improve Toolbar #18619 from @diegohaz.)
• The parent toolbar might need to absorb the children toolbar in certain conditions. (See Nested Blocks: Provide container block prop to absorb child block UI #17267.)
• Too many icons are being used, especially in drop-down menus, reducing legibility and blurring hierarchies.

Reflecting upon this situation, a few principles emerged:

• The toolbar has to be a natural extension of the direct manipulation aspects of the block content.
• The toolbar can be contextual and accommodate a wide range of tools, both general to all blocks (movement, duplications, removing, etc) and specific to the current block (transforms, settings, shortcuts, etc).
• The Toolbar needs to adapt. Toolbar controls need to be grouped, collapsed, and expanded based on context. This contextuality extends not only to different blocks but also to specific states of individual blocks.
• Clarity and contrast is fundamental. It has to remain a clear element against all backgrounds and conditions, including complex nested contexts.

Let’s Explore!

Looking at all these considerations we can start piecing together paths of exploration for a more refined block interface that emphasizes clarity and function while reducing how many elements are floating.

• Composing, grouping, and reducing design elements, colors, materials, and shapes allows to bring controls together and concentrates focal points within the editor interface.
• From the get go, higher contrast can be used to ensure only the important lines prevail.
• Reduce the overall floating interface and navigation steps (particularly for keyboard) by absorbing movers and its dragging anchor point into the toolbar.
• • Related exploration by @richtabor in Block Mover: Try cleaning up the control UI #16580.
• • This is greatly highlighted by the horizontal movers Navigation block: Add horizontal movers #16637 in the recent Navigation block.
• • See also Block movers are funky when block is align-right or align-left #18069, Child block side UI doesn't reposition in align-wide/full #7646, and Column Block: Movers for Full and Wide Images inside columns are not visible #18195.
• The absence of a clear grid in the current block UI is exhausting the cleanliness, consistency, and scalability of the toolbar. Working with a grid, both horizontal and vertical, helps with coherence and spacing. It seems to work well in multiples of 12px.
• Freeing the toolbar from the block margins affords wider and more immersive content and layout. It also can lower noise in nested cases.
• The toolbar becoming more contextual, controls appearing in relevance of the state of the block, focuses the users in the action at hand.
• More discreet and related elements can lift some visual tensions and noise in such a tight interface.

Absorbing the movers into the toolbar can become a contextual action, simulated in the following GIF.

The movers have a more clear relationship to the block type they are affecting, which can also help refine the drag-and-drop behaviour.

Drop-downs can be recognized as extending from the same elements as the toolbar itself, reducing the amount of unnecessary icons, and improving contrast and clarity.

When looking more broadly to the block we can also apply some of the same principles to reduce materials (outlines with different weights) and benefit from the reduction the toolbar allows. Combining this with the work done on the “navigation mode”, the outlines can become a more effective system to communicate states and interactions.

An important aspect is that outlines for block selection can remain consistent, including those employed during navigation mode, ideally helping with issues like #17184:

Combining the movers with the toolbar also helps tremendously in some of the scenarios where the current model fails — like the use of horizontal movers in Buttons or the Navigation block:

It’s also interesting to see how these principles can help extend the toolbar to the placeholder element, so that the initial setup of the block connects better with later interactions, retaining an element of familiarity:

---

This is just to kickstart the conversation, I think there’s a lot of potential in thinking about all these problems more holistically from a design, usability, and accessibility perspective. Huge kudos to @pablohoneyhoney and @jasmussen for playing with these ideas a bit.

There’s a lot more ground to cover and explore. What do you think? Does it spark any other ideas? If you have been working with blocks and experiencing the rough edges, does it solve some of them?