Move the blocks "More" button (ellipsis) to the toolbar

[jasmussen]

The "More" button for blocks is increasingly becoming more useful, to the point where it now contains features that are starting to become critical to the use of the block

But in being auto-hiding side-UI for the block, it is not as discoverable as it perhaps deserves to be.

Additionally, when the block is shown in nested contexts, there are often stacking issues with the side UI. This is also being discussed in #6224, and although removing just the More button doesn't solve that, it mitigates it a fair bit by addressing some of the stacking issues you might see if you have two blocks side by side.

In that vein, moving the More button to the toolbar improves two issues:

1. Discoverability
2. Nested block UI

The challenge this brings with it is: the block toolbar grows wider. How do we address this especially in nested situations? This is something we need to tackle even without the More button in the toolbar, so let's look at addressing that as part of #9075.

Mockup:

Tasks to accomplish this move:

• Move More Button/ellipsis from side UI to toolbar
• Make sure it works with a fixed to the top toolbar, and with multi select

[youknowriad]

The less tool areas we have, the better is 👍

Can’t we always right align the more menu in the toolbar though? and make the toolbar 100% width?
It makes it clear that it’s not just another toolbar control

[jasmussen]

Here's a mockup showing the toolbar be 100% full-width:

I don't personally have a strong opinion either way.

[chrisvanpatten]

I definitely prefer the look of a full-width toolbar, but it does decrease the surface area available to click through to the block above. Visually, though, it's great.

This is a great step, and I am hopeful it can make it in!

[ZebulanStanphill]

I think I would prefer it to be on the left for the sake of taking up as small an area as possible, but since having it on the right provides a large potential drag area, I really would not mind that much either way. Left or right, I think this is a good move and a definite improvement over master.

Also noting that the issues mentioned in #8880 would be significantly reduced if this was implemented.

Please, please, please do this.

[talldan]

Does the icon in that location make it seem like it might display more formatting tools? That was my first reaction, I think because of the similarity of the icon to an ellipsis.

I prefer the mockup with it on the right for that reason.

[jasmussen]

Does the icon in that location make it seem like it might display more formatting tools? That was my first reaction, I think because of the similarity of the icon to an ellipsis.

Possibly, though I don't think it's a big issue since it takes a single click to learn what's in that menu, and what's there is always the same across blocks. I definitely understand what you're saying, but I don't think it's a blocker to the discoverability issues moving the button there solves.

Note that even if we do go with the button on the right, in thin contexts the button will still snuggle up next to the other icons as the toolbar grows thin.

[jaclyntan]

I think this is a good solution and I definitely prefer the full width version with the dots on the right.

In the current version the dots are in an annoying and unhelpful position, where it looks like an icon I'd use to drag and reorder the blocks - not for editing critical info for the block itself.

[talldan]

One other challenge is that currently the block settings menu can be clicked without the block being selected - it just needs to be hovered. The toolbar behaves slightly differently and is only visible once the block is selected.

@jasmussen Would be good to understand how that side of things works for your proposal in the issue description.

[jasmussen]

One other challenge is that currently the block settings menu can be clicked without the block being selected - it just needs to be hovered. The toolbar behaves slightly differently and is only visible once the block is selected.

Yes, this would be a tradeoff: in this design, the ellipsis menu is only available after first having selected the block.

However I think this tradeoff is worth it.

[ZebulanStanphill]

@jasmussen I agree, the tradeoff is definitely worth it, especially now that there are keyboard shortcuts for most of the options in the ellipsis menu.

[karmatosed]

I think having it far left on larger screens makes sense and keeps the visual patterns a little easier to understand.

[oandregal]

Would it make sense to use this toolbar as the drag handler? It could help alleviate some problems with refactoring drag and drop to use the hover label (there is no hover label for classic blocks and the selected block doesn't have it either). If we wanted to do so, we'd perhaps want to show the toolbar on hover instead of selecting a block. It'd help to discover the options menu (now it's shown on hover) as well as the drag-n-drop handle.

[ZebulanStanphill]

@nosolosw I think the toolbar (as in, the whole thing including the buttons, like what GNOME does) should be a drag handle, but that does not mean it should be the only one. The up/down movers could also double as a drag handle, which would be available on hover.

I would strongly caution against showing the toolbar on hover. The UI for hovering over blocks should be as light as possible, and my mockups in #6224 were often shot down for this very issue. Even my latest one is still considered too heavy, and I can't deny it does add quite a bit of weight:

(I think that for my next mockup, I will leave the up/down movers on the side and turn the sibling inserter into a floating control that looks and acts similar to to the up/down movers, but appears below the block.)

[jasmussen]

Would it make sense to use this toolbar as the drag handler? It could help alleviate some problems with refactoring drag and drop to use the hover label (there is no hover label for classic blocks and the selected block doesn't have it either). If we wanted to do so, we'd perhaps want to show the toolbar on hover instead of selecting a block.

I don't think we'll want to show this toolbar on hover, as this only adds weight to an already heavy UI. I know that @mtias has some thoughts on drag handles.

[youknowriad]

Question here: Where to show the menu if the "toolbar is fixed to top" especially if we choose to right align the button?

[jasmussen]

Question here: Where to show the menu if the "toolbar is fixed to top" especially if we choose to right align the button?

Same as today, and we would not right align the block ellipsis, it would have to be present in sequence with the others I'd think.

[mtias]

This should also apply to multi-select (would be good to have one mockup for it), which largely depend on also having the multi-select toolbar ready.

[jasmussen]

Here's a very quick and dirty (metrics don't match) mockup for multi select:

Also, the PR for multi select toolbar seems underway here #7635

[mtias]

That works much better than what we have, I think.

[folletto]

Some random feedback points:

1. I find great to reduce the number of "tool areas", as Riad said. Definite +1 from me.
2. I find the "100% full-width" version to be difficult because it will cover the entire line of whatever is above, instead of minimizing the covering impact. Also: large screens will split the two too much (same problem we have now tho so not a regression, but would feel more stretched).
3. I agree with Zebulan that it shouldn't be on hover, same on being "a drag handler but not the only one".
4. When "toolbar is fixed to top" I think would be totally fine in having the ••• menu there too. Seems more consistent and intuitive if the whole bar moves.
5. It also seems more consistent on mobile, which is a great win as mobile is massively important. ;)

[youknowriad]

@jasmussen on multi-selection, sometimes there's no block switcher, is it fine to show only the more menu in that case?

[youknowriad]

Sorry, these buttons are too close :) (comment, comment and close)

[jasmussen]

on multi-selection, sometimes there's no block switcher, is it fine to show only the more menu in that case?

Yes then it's just the more menu.

[ZebulanStanphill]

One thing that just occurred to me is that this change would make it considerably easier to interact with floated blocks, because the option to remove them would now be right above them, rather than on the far right even when the block was floated to the left.

Of course, the up/down movers would still have the same issue that the ellipsis had, but this would definitely be an improvement over the current situation. If you could use the toolbar as a drag handle, then that would reduce the moving issue, though it would not be fully resolved, as the up/down movers should always be usable, with drag-and-drop being a secondary bonus.

Similarly, the overlapping ellipsis menu issue you get with blocks on the right column of a Columns block would be fixed as well.

In general, I think this change would fix pretty much all the issues with the current ellipsis menu button. 👍

[youknowriad]

closed by #9572