Block Toolbar/Movers: Revisit groupings and align to a grid

[jasmussen]

The block toolbar was unified into a single interface to solve numerous problems with the 5.4 block toolbar. Including the need for a separate interface for mobile and desktop:

An arbitrary padding left and right in the editing canvas to accommodate the mover control on the side:

The mover interface shifted into the toolbar on fullwide blocks:

Toolbars would overlap horizontally and get cropped in nested contexts:

Mover controls were cropped in fullwide container blocks:

Block UI could be bigger than the block itself in some cases:

The toolbar that did not scale to plugins adding virtually any additional buttons at all:

The mover control was entirely different for lateral movement:

Unifying the block toolbar provided an identical interface regardless of whether the block was fullwide or floated or in any other context:

It works on any color background:

It's detached, so it does not get cropped in nested contexts:

The mover control works for any blocks, including movers, with the same interface for vertical and lateral movement:

---

With the unified toolbar, though, there were concerns about the integrated drag and drop behavior, and for the grouping of buttons inside toolbar groups. This ticket aims to revisit the grid, separation, and functionality of the block toolbar with emphasis on groupings and consistent spacing. It does so through a few efforts:

1. It separates toolbar items in 4 distinct toolbar groups: block, block level, inline level, and more.
2. It unifies spacing the spacing to match the 12px grid. Icons are 24x24, and the spacing between is 12px.

The problem with drag and drop is that when the toolbar is in top toolbar mode, a drag handle on the toolbar won't help. Issue #24092 aims to address that by enhancing the select mode. Let's continue discussion there.

Mockup:

The consistent spacing drastically simplifies the CSS for toolbar groups, and makes the group behavior consistent regardless of whether buttons are part of the core block, or added by a plugin.

The grid becomes more visible when comparing to the 5.4 block toolbar, and click areas remain consistently 50-70% bigger, across the board.

Even if the toolbar does scale to any size (through being detached and even able to scroll horizontally), there is still value in keeping the weight of the toolbar reasonable. This hopefully gets us closer to that.

[afercia]

Nice to see better grouping, better spacing, and better clickable areas being defined. Couple things:

As mentioned also in #24805 by @ZebulanStanphill and I, at a first glance the mover buttons really look like a single button:

This is no different from what it is in 5.5 and I think it doesn't contribute to make the UI clear and intuitive. On a general note, I don't think that "squeezing" user interface controls just because there's not enough space is a good solution in the first place. If the toolbar can't contain all the needed controls maybe worth considering if the concept of toolbar itself serves well this use case.

Secondly: the mover buttons clickable area is still very small. I have seen efforts to improve this specific issue and that's appreciated but still... these buttons are small 🙂 In my usage experience, it's not so uncommon to click the wrong button and move the block in the wrong direction.

Also, in the "top toolbar" mode, these buttons are smaller than what they were in WordPress 5.4 so I'd argue the new design is an improvement.

Screenshot of the mover buttons in "top toolbar" mode in WordPress 5.4:

and in WordPress 5.5:

[jasmussen]

Here's a mockup that includes the draggable handle, as it is also included in the mockup for drag and drop in select mode:

[ZebulanStanphill]

The drag handle seems a little too small to me (I think it should be 36px wide, matching the minimum button size in toolbar groups), but I think the mockup is still better than what we have in master since it at least the drag handle is visible, and the drag handle being between the icon and mover arrows helps to make it clear that the arrows are separate from the switcher.

[shaunandrews]

I don't think that "squeezing" user interface controls just because there's not enough space is a good solution in the first place. If the toolbar can't contain all the needed controls maybe worth considering if the concept of toolbar itself serves well this use case.

The reason for placing the move up/down buttons one on top of the other isn't because there's not enough space; Its because it makes more visual sense — These two buttons are related, and it feels natural for them to be connected.

When the buttons move the block vertically, they stack vertically. When they move the block horizontally, they stack horizontally. Separating the buttons into two distinctly individual functions reduces the clarity of the design.

[jasmussen]

The drag handle seems a little too small to me (I think it should be 36px wide, matching the minimum button size in toolbar groups)

Worth noting that at 24x48px the drag handle is 71% bigger than what shipped in WordPress 5.4.

In the end, what we're discussing here requires us to make choices like this: what is primary UI, and what is secondary? In this case, drag and drop intrinsically requires fine motor skills, regardless of how big the handle is; drag more than short distances and you might scroll the entire viewport. It is for that reason, among many others, that the explicit up and down mover controls are the primary and emphasized controls, and another reason why perhaps the better interface for drag and drop is in the select mode, where the entire block footprint is the draggable area.

[afercia]

The reason for placing the move up/down buttons one on top of the other isn't because there's not enough space; Its because it makes more visual sense — These two buttons are related, and it feels natural for them to be connected.

Nevertheless, they're too small, really too small. With the "top toolbar" enabled, these buttons are way smaller than what they were in WordPress 5.4. Many users have trouble to use them and I'd say that functionality should always come before any "visual" consideration.

Also, as I mentioned in another issue, the toolbar implements keyboard navigation with the left and right arrow keys, that is" horizontal movement. The toolbar also communicates semantically its orientation by using these ARIA attributes:

role="toolbar" aria-orientation="horizontal".

When using the left or right arrow keys, I expect a horizontal movement and it feels really weird that the mover buttons are navigated vertically instead.

These two buttons are related, and it feels natural for them to be connected.

I'd like to repeat what I already said in a previous comment: they're so connected that at a first glance they really look like a single button (this was already mentioned in #24805 by @ZebulanStanphill and I):

Looking at the above UI, at a first glance the toolbar design is communicating me that all buttons have the same size. I have no reasons to even imagine the two up and down arrows are actually two separate buttons. This exception to a pattern that is well established by the other buttons is confusing and I'm not sure it contributes to make the design clearer.

Lastly, since the buttons are stacked vertically, the tooltip of the "move up" button hides part of the UI and I'm not sure this is a good experience for users

More importantly, before this kind of changes are implemented and released, I'd really appreciate to see them user tested. I don't think a web publishing platform that powers 38% of the web can rely on assumptions made by a small group of designers and release new UIs without any user testing. User testing should include users with accessibility needs and users of assistive technologies.

The only fact we're discussing at length this issue proves that some aren't comfortable with this new UI as users in the first place. I find these small buttons difficult to use and often end up in clicking the wrong one and I don't think this design is functional.

[afercia]

Also to note: #15345 where there was general consensus about making all buttons generally bigger.

[pablohoneyhoney]

@afercia I'd avoid using general consensus as a tool for decision making, when clearly there are people who don't agree with this point (like myself). @jasmussen states and explains in detail above as well.

While there are always things to be improved, the reality is that the UI in 5.5 has increased considerably, and the buttons you are referring to are 50% bigger, if that matters.

[afercia]

@pablohoneyhoney it's curious to note that in #15345 @jasmussen himself agreed on the general principle:

#15345 (comment)

The bigger the button

Of course, it's perfectly fine to change your mind but these continuous changes to design principles and decisions already made previously don't contribute to make a better product, IMHO.

the buttons you are referring to are 50% bigger, if that matters.

This is not 100% correct: with "top toolbar" on, they're actually way smaller. Regardless, it's the perception they're smaller, the fact they're close each other while previously there was non-clickable space around them, that makes them more difficult to use and IMHO not an improvement.

[jasmussen]

@afercia Please don't paraphrase my comments to fit your own statements. It's obvious that the bigger a button is, the easier it is to hit, it's math. But that doesn't mean every button can be infinitely big, a balance has to be reached.

In 5.4 mover controls were 24x28px, i.e. 672px total hit area. Merged into master currently, mover controls are 42x24px, 1008px total hit area. That is an increase of 50% exactly. Their size in top toolbar mode is identical.

[ZebulanStanphill]

@jasmussen In 5.4, the mover buttons were separate in the top toolbar, while now they are stacked in 5.5, causing their size to be smaller.

[ZebulanStanphill]

The problem with stacking the movers is that it's inconsistent and breaks user expectations. Every other button takes up approximately the same amount of horizontal space, and always the same vertical space. The stacked movers look like a single button, because they take up the space that a single button would usually take up. Additionally, their vertical orientation does not fit with the semantics of the toolbar being horizontal.

Stacking the movers does not make their relationship more clear. Their icons (and the fact they're right next to each other and a drag handle) should already convey that. (Speaking of which, we really shouldn't be using the same icons for movement as we do for accordions and dropdowns.)

The horizontal movers don't have the orientation problem, but they still have the problem of being two buttons that take up the same amount of space as a single one should. And unlike the vertical movers, where there's a max height for the toolbar, there's no max width, so there's even less justification for the buttons being half the usual size.

Is it too much to ask that the mover buttons just look and act like every other button in the toolbar? As far as I can tell, the only reasons they're stacked are:

• to look cool (not a good enough reason to break consistency and user expectations)
• to try and "save space" (that's just an excuse to avoid solving a larger problem that needs to be addressed)
• supposedly, stacking the vertical movers makes the purpose of the buttons clearer

That last one does not appear to have any basis whatsoever in actual user feedback/testing. I don't see how unstacking the movers would make it less clear what the buttons do. With all that in mind, I believe the custom look of the movers is an unnecessary UI complication created solely to please designers making questionable assumptions about what users want.

And it's not like it's a harmless design thing. There are clear a11y/usability downsides to the current approach, so unless you intend to get proper user feedback to determine which design is preferable, I think that for now, we should fall back to the safe, simple, and consistent solution of making the movers look like all the other toolbar buttons.

In contrast, the only downside to unstacking the movers (as far as I am aware) is the fear of making the toolbar too long. And if that's such a big concern, then perhaps we ought to focus more on solving that issue. But aside from that issue, there's nothing to lose and quite a bit to gain.

[afercia]

@afercia Please don't paraphrase my comments to fit your own statements. It's obvious that the bigger a button is, the easier it is to hit, it's math. But that doesn't mean every button can be infinitely big, a balance has to be reached.

@jasmussen I don't think quoting someone else is wrong in any way. This entire project is full of quotes, links to comments, etc. Also my comments are quoted and linked across issues and PRs and I don't get offended for that. But if you felt uncomfortable with that, I do apologize.

In 5.4 mover controls were 24x28px, i.e. 672px total hit area. Merged into master currently, mover controls are 42x24px, 1008px total hit area. That is an increase of 50% exactly.

As I mentioned previously it's not just their size. It is also about:

the perception they're smaller, the fact they're close each other while previously there was non-clickable space around them, that makes them more difficult to use and IMHO not an improvement.

Since there's no free space around them any longer the chance of misclicking them is way higher. To me this is not an improvement and I'd kindly ask you to please respect my professional opinion.

Their size in top toolbar mode is identical.

This is the top toolbar in 5.4:

And this is the top toolbar in 5.5:

I wouldn't say those buttons size is "identical".

[afercia]

Reading latest comment from @ZebulanStanphill I'd totally second all that.

I'd like to add that when navigating the toolbar with the keyboard by using the left and right arrow keys, it's really weird to see focus moves vertically while I'm using keys that suggest a horizontal movement. I always get confused when arrowing on the mover buttons and I'm often uncertain on what key to use.

we really shouldn't be using the same icons for movement as we do for accordions and dropdowns

Oh yes, that 🙂 Also, in the rest of the admin, the chevron icon have been traditionally used for "reorder", see for example the Customizer widgets and menu items reordering mode.

[mariohamann]

Personally I would prefer having the buttons side by side for several reasons:

• The size of the stacked buttons is really small and therefore they are harder to use at least with touch (see Nielsen Norman Group's article about Touch Target Size or the specs in Material Design)
• I think it's not ideal if the same interaction doubles its size only because the orientation changes (moving left/right vs. moving top/bottom). Especially while using the top toolbar in my opinion this produces unnecessary visual jumps.
• The behaviour while using keyboard is very confusing (see @mapk's Keyboard navigation in block toolbar is confusing #25465)

I would like to add an example from GitHub's smartphone app:

For me it was never irrititating that the buttons are positioned side by side – but on my smartphone I often encountered the problem of accidentelly clicking on the white area which sorrounds the buttons and opens the bottom area, leading again to "please make buttons big enough for touch". :)

[jasmussen]

Since this ticket was created, a separate drag handle was added, and numerous refactors of the toolbar were made across mobile and desktop. As such, the initial goal of this ticket has been addressed. If there's a desire to revisit the movers, this is best revisited in a fresh ticket that looks at the block toolbar as it is today.