Repository navigation
Advancing the Block Interface #18667
Description
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.
- 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?
Activity
richtabor commentedon Nov 26, 2019
This is great @mtias, really forward-thinking. 👏 👏
Here are a couple notes I had while reading through the issue:
I'm curious what this means for the "Top Toolbar". What parts of the interactions do you imagine becoming ingrained there?
The last screenshot references a color UX pattern. Baking in an easily implemented foundational colors experience would be so fantastic for blocks! Having background/text color controls in a standardized locale would lead to a much needed pattern for applying colors.
I'm not sure if it's been explored yet, but it may be interesting to explore having the toolbar remain static on the parent block while nested blocks are being edited - with controls adapting based on the selected child block.
What does the little black triangle at the bottom right of the block icon? If it means that there's a dropdown with additional controls in it? If so, the alignment/text alignment controls should also have it.
jasmussen commentedon Nov 26, 2019
I think Matías is on a flight today, so I'm doing my best to answer in his place. I'm sure he'll chime in if I'm off base!
This is something we'll need to explore and address in implementation. The focus has been primarily on the default experience, which has the most literal visual context to each block being edited, but the top toolbar option should remain an option for those who prefer. Whether this means always showing the mover control, or making sure there's space for it to appear without moving the toolbar, there are options here.
🙌
I believe #18440 (addressing #17267) might be along the lines of what you are suggesting here. I happen to agree with you this is necessary for at least some container blocks!
Dropdowns are likely to be increasingly necessary in the toolbar, not just to scale (the alignments menu which could theoretically grow to include custom flexbox alignments), but in order to better address plugin, responsive, and nested contexts.
In this exploration, dropdowns do not have additional visual indicators, which is consistent with popovers like the Block Library, Block Traversal and Ellipsis menus. It remains to be seen in implementation how intuitive this is for all sorts of users, but the idea is to reduce and simplify a very complex control. The triangle for the block item instead becomes an anchor point for the block, indicating the toolbar segment from which all others expand.
ZebulanStanphill commentedon Nov 26, 2019
Regarding the move controls, how would these changes affect accessibility? What would be the tab order for the toolbar controls? Is it bad for accessibility to have the move controls only be shown when hovering the block icon?
jasmussen commentedon Nov 27, 2019
Good questions, Zeb! Finding the right balance with the mover control is of great importance. On the one hand they offer a clear interaction for easily swapping two blocks around in a manner that is mobile friendly and not as fiddly as drag and drop, which is important for people with reduced motor skills.
At the same time, it's a big control that is useful only some of the time. Same as the sibling inserter — the plus that sits between two blocks — the idea outlined in this ticket suggests that the control could be hidden until needed.
Tab-order-wise, the controls could potentially be in a better place than before, as there will now be a single block toolbar control to tab into. Just like the sibling inserter is surfaced on both hover and focus, so would the mover controls, and they would come before the rest of the controls in the toolbar.
As I also noted to Rich, the mover control is one of those aspects that will need to be refined as we explore it in code. The intent is to find the right balance between utility and accessibility, there are a few ways we can go with it.
mapk commentedon Nov 27, 2019
I'm really excited to see these evolutions!
I recall another challenge we face is having UI appear and disappear with various hover and selections. While this exploration still allows this, I believe grouping the UI into one cohesive toolbar as shown here will help resolve the problem. 👍
The stronger contrast is beautiful. 😍
We definitely need to put this to the test. It would be fun to explore in the context of:
Basically exploring how this new toolbar works in relation to what was addressed here (some of this is already being done):
This will help keep us focused on the whole.
mtias commentedon Nov 27, 2019
It's a good question. The top-toolbar is mostly in a decent place, since it doesn't suffer from many of the problems the in-canvas toolbar has. I'd expect it'll inherit some of the main improvements (clarity around drop-downs, contextual tools, differentiation of ellipsis menus — which the header has two —, focus states, etc).
There are some challenges to the header area that I think we need to look at more holistically, especially with full-site editing which is likely going to bring more controls within a limited space. I could see, for example, top-toolbar not adding the controls to the header but immediately below it if we can work out the double-stacking not looking horrendous :)
Agreed! I think we are getting to a point where the UI work can help us drive issue like #7553 and #9534.
What @jasmussen said. Also it's meant to emphasize the dropdown and add a level of hierarchy to the block type, which has been absorbing more interactions (transforms, styles, selection, possibly more).
ZebulanStanphill commentedon Nov 27, 2019
I think long-term, something like this is inevitable. Semantically, it seems weird to combine the general toolbar with the block toolbar, and having the two on separate lines would allow controls on both to be given optional inline labels (see #10524) without getting really cramped.
48 remaining items
Try: High-luminance default colors
Try: High-luminance default colors
Try: High-luminance default colors
oldrup commentedon Mar 13, 2020
Using Gutenberg for all my post, I most say, I find it faster to recognize the icons in the menu, than the text, and I don't find the removal of the icons an improvement. Increasing acceptance and usage of Gutenberg, is also about making it friendly to new users. Stripping out friendly icons deemed "unnecessary" does not help with that.. (Purely my opinion - got no user tests to back that statement)
paaljoachim commentedon Apr 22, 2020
I just want to comment on the icons comment from @oldrup
We can recognize something visually as an image or through text. Having icons beside the text really helps create an even better recognition of what we are looking at. Using an icon we will gradually build up a recognition and when we see the icon in another location we will automatically understand what it represents.
ellatrix commentedon Jun 6, 2020
Is there anything left here? :)
jasmussen commentedon Jun 8, 2020
Yes! Lots! There's the realignment of menus, there's lots of work to do in the sidebar to reduce and align to a grid, and work is never over.
I don't object to this ticket being closed, as the primary points of the refresh are addressed, and actionable followup issues can be created separately.
ellatrix commentedon Jun 9, 2020
Is there a tracking issue for he realignment of menus? Would be good to get into 5.5.
annezazu commentedon May 17, 2021
Since it's been nearly a year since this has been expanded upon and much of it was merged into prior WordPress releases, I'm going to close this out! Awesome work across the board for everyone who helped drive this forward.
Simplify first principle and improve the description.