Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
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
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:
(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:
Reflecting upon this situation, a few principles emerged:
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.
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?
This is great @mtias, really forward-thinking.
Here are a couple notes I had while reading through the issue:
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.
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.
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.
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.
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 :)
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).
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.
I am excited about this iteration and appreciate it started by distilling back to the block. I want to dive a bit into this with some thoughts that come to mind. The first of those is how critical noting it's been a year is. It's crucial the interface evolves, responds and adapts to what is today's space and what will be in future. There's a lot we've all learnt along the way that can be fuel for this iteration. I think it's also worth pointing out this itself should be an iteration, with more to come.
A big problem currently is as the interface gets more complicated with nested blocks and content, the current situation doesn't scale. That feels at the root of going back to the block and re-examining. I think the suggestion of for example moving the block movers solves such a big piece of this. The toolbar suggestions as a unit to me feel instinctively like a significant step forward. It is also worth noting some benefits come in usability just from having the bigger hit space; there's an opening of the interface even that soothes cognitive load.
I am very keen on bringing in a grid and feel this as spreads across the experience is going to reduce visual confusion and space for comprehension of the experience as a whole.
As I look at the examples, wayfinding seems more natural; this is a significant improvement and one of friction today. Being able to see what you are doing and when is even more crucial as the move to site editing ramps up. While it's not being visualised in complex content in those examples, I can see how this would at least be a lot more easy to focus on than what we have currently.
It would be great to as part of this iteration explore not only the visual language but the interaction one. What story can we tell, what can we enhance with the animations, dragging and bounces? There's never been time for crafting of this into a story arc, pacing. Similarly, taking the time to make an audit of what interactions we have seems right. By setting up an interaction language the experience will improve dramatically along with all the other improvements proposed. In the examples shown, I am optimistic about this being part of the work.
I think there are a lot of really compelling ideas in this ticket! I don't have a ton of things to comment on (as I like a lot of what's being said!) but one thing I want to observe is the continued prevalence of "hover" actions.
I recently switched to an iPad as my primary computing device, and it's an environment where hover events simply aren't possible. Safari in iOS 13 does its best to interpret touches as hovers and map it appropriately, but it works inconsistently and is clunky at best. And even though iPadOS technically supports mice, it doesn't allow tracking hover events as the mouse pointer is treated as an analogue for touch input.
I know there are also accessibility implications to hover events, although I'm not really comfortable speaking to those. But more generally as iPads and touch devices become more common (and specifically become more common primary devices) it would be great to start from a place where hover is treated as a progressive enhancement.
@chrisvanpatten I agree; I want to see a mockup of how the proposed new toolbar would work for mobile. Perhaps tapping the block icon would cause both the mover and the transform/styles menu to appear?
Another thing I'm curious about is how the mockup toolbar works in tight situations where the block toolbar is right up against the left side of the screen. If the hover controls always slide out to the left, how are you supposed to use them if they go off-screen? Will the block toolbar always be positioned a minimum distance away from the left edge to ensure there is room for the mover to appear?
A small note from the angle of the user. I share the sentiment that we should take into account touch devices as the current experience on the iPad isn't great even if you use it with the smart keyboard to boost your productivity. In general, we reached the point where the number of visits from mobile devices is bigger than those for desktop computers so we should ensure it feels great in all cases.
Definitely. "Hover / Focus" in the presentation is generally interchangeable with a similar tap-step on touch devices, which would need to be properly defined.
The biggest blocker we had on mobile for a more usable toolbar has recently been addressed in #18686.
And perhaps even surface a "move to" so that you could tap, scroll to where you want to move the block, and tap again to drop a block:
Nice mobile mockups.
Something else I'm wondering: why should the movers be on the left of the block icon? If the block icon is the "anchor" point of the toolbar, I'd think that it should be the first thing you tab into, and therefore the movers should appear after it.
I recorded a walkthrough of my prototypes here:
Linky to code and things!
Awesome, @ItsJonQ! Thanks for the amazing work!
The first thing I noticed playing with that is that people with motor disabilities or anyone who has difficulties using a mouse may struggle with the collapse effect.
I'd say that this would affect anyone at certain level.
Debouncing the collapse effect may help with that.
@diegohaz Thanks for the feedback!
I've been noticing some interaction challenges myself. And I think my motor skills are okay. So I can imagine the challenges others may have.
Based on your feedback, as well as feedback from others, I've added an option to see your mouse trail.
I think this will help visually demonstrate how easy/difficult an interaction is:
I think this tool can help us refine some interaction/UX ideas :)
I'll give that a try!
x-posted from #18685 (comment)
After playing around a bit...
I have an alternative interaction pattern idea that tried to lighten the UI re: movers.
(I don't know if this was tried previously).
The idea came from playing around with Notion (they don't use arrows in their mover though).
These are my initial thoughts + observations
For this reason, I think it would be best if the mover controls were merged into the block toolbar, since combining that with an option to show the toolbar below the block would provide a better keyboard experience than what we have now.
I'm not a fan of having the mover slide out upon hovering the block icon. That feels too hidden to me. I think a better solution would be to put a drag handle to the right of the block icon which is always visible. Hovering or tapping the drag handle would cause it to expand and show the arrow controls. Tabbing into it would also cause it to expand, with focus jumping to the arrow controls (because the drag handle is useless to keyboard users).
Another thing to keep in mind is how the move control — if it's a single draggable button — will be accessed by keyboard users.
One option is to activate it by pressing Enter or Space and then use arrow keys to move the block around. When it changes, screen reader users should be notified about the new block position (maybe using aria-live regions).
The user could press Escape to exit this mode and then use arrow keys to move between the toolbar items again.
Maybe that's a better UX even for sighted users? The current behavior has a very poor UX in my opinion. When you use the draggable handle, it's difficult to find the right spot to drop it. And subsequent clicks on the arrow buttons are slow due to the position change (you can press Enter multiple times while focusing the arrow button though, but that doesn't feel intuitive enough).
In light of the comments and ideas above, here some further explorations on movers. I'm hopefully capturing the collective sentiment and the individual nuances, we can all keep exploring in the open figma file: https://www.figma.com/file/fnyj380i05vGzuuH60frLQ/G2-Design?node-id=85%3A6975
And we can also translate these in interactive models @ItsJonQ to see them in action.
Option 1: Contextual, where the movers appear when relevant.
Option 2: Visible by default, while the block type loses its nature as an anchor point.
Option 3: Movers live on the right side of the toolbar.
Option 4: Relying on a drag behavior, while it becomes a difficult motor skill for users of all types, even on desktops.
Thoughts on the block mover
I think whatever design we go with must keep the individual buttons for moving a block up/down (or left/right). Relying on a drag handle is bad for accessibility, and the arrow buttons are often faster and easier to use anyway. Drag-and-drop should be a secondary enhancement.
I also would strongly advise against making the arrow buttons too small. They should be easy to tap with a touchscreen at all (not just mobile) viewport widths.
#18685 (comment) currently implements the movers as two separate arrow buttons that double as drag handles, thus reducing the size of the mover while increasing the size of the drag handle.
The mover could still be made to only appear when hovering the toolbar or after clicking something (perhaps a button that expands into the full mover when clicked), but there needs to be 2 normal-sized arrow buttons somewhere in the design.
Concerning where in the toolbar the movers should go, it may be helpful to consider it in terms of keyboard navigation. When tabbing into the block toolbar, what tab order of controls makes the most sense? Whatever the answer is, it should be used as the basis for the visual order.
Thoughts on the block toolbar structure in general
Currently, the block toolbar seems to have an order based on putting block-level controls on the left and inline controls on the right. The block transformer/switcher affects the whole block (and in some cases changes the block type), the block alignment dropdown affects the entire block, and then the inline formatting tools only affect portions of the block.
However, there is an exception to this rule: the "More options" menu. This menu contains only options that affect the entire block, yet it is placed on the right side of the toolbar.
Now consider this: the block switcher/transformer is placed under a button with the block icon. At first glance, it looks like this button should open the menu for the general settings of the block. To an extent, this is true, with the transforms/styles placed there. However, the rest of the general options are thrown in the ellipsis menu.
The styles are put into a sub-menu, and technically the transforms could be put into one as well. (And perhaps they should, given the large number of transforms for some blocks like the Paragraph block.) Alternatively, both could be turned into buttons that open a modal to give more breathing room for the available options (including more space for previews).
Why not take this a step further and combine the block icon menu with the ellipsis menu?
Alternatively, what if the block icon button took over the role that the ellipsis menu currently serves, and the block styles and/or transforms were moved into a separate button on the toolbar?
The new native selection style is much faster and an important step on the path to various writing-flow improvements. However until we can get closer to those improvements, in the mean time selecting multiple blocks is currently slightly less clear than it was prior to the native selection change. In #18867 I tried to mitigate this, and it includes some mockups for how to improve the style longer term, with more thoughts being discussed in #18667. But until that gets hashed out more clearly, perhaps we should rewind the visual style slightly, to be closer to what was, while still keeping the technical benefits of the native selection PR. This PR keeps those changes, but tweaks the visual style. What it does is remove the left border style, and re-paints a cross-block background. But this time with a color that is closer to the default selection color on Windows and MacOS. Specifically, both those defaults are eye-dropped and averaged to create a new color that looks at home on both. It is possible users can customize this select color, meaning the color of the selection marker inside text will diverge from that of multi-block selections. But this is unfortunately not something we can address. But the averaged color feels like a pretty good interim step towards a selection model that is perhaps closer to that of Figma, painting borders around each block instead of re-coloring the background.
From my initial read I’m excited. The changes that are being proposed feel like a breath of fresh air to the interface. The words that come to mind are simple and calm.
Making things more contextual to the block also makes sense. I wasn’t sure about bringing the movers into the toolbar initially, but seeing how they can be converted to horizontal in context would be more useful. Also, I see there's been discussion about whether they stay visible at all times or not. That's something I'm not sure about myself.
Agreed! Felt so relaxing to look at that new contrast.
Would love to see where we can explore motion!