Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
2 tasks
jasmussen opened this issue Aug 17, 2018 · 25 comments
Closed
2 tasks

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

jasmussen opened this issue Aug 17, 2018 · 25 comments
Labels
[Type] Enhancement A suggestion for improvement.

Comments

@jasmussen
Copy link
Contributor

jasmussen commented Aug 17, 2018

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

screen shot 2018-08-17 at 11 06 09

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.

screen shot 2018-08-17 at 11 07 31

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:

wide

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
Copy link
Contributor

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
Copy link
Contributor Author

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

screen shot 2018-08-17 at 11 28 05

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

@chrisvanpatten
Copy link
Contributor

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
Copy link
Member

ZebulanStanphill commented Aug 17, 2018

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
Copy link
Contributor

talldan commented Aug 20, 2018

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
Copy link
Contributor Author

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
Copy link

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
Copy link
Contributor

talldan commented Aug 20, 2018

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
Copy link
Contributor Author

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
Copy link
Member

@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
Copy link
Member

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

@karmatosed karmatosed removed the Needs Design Feedback Needs general design feedback. label Aug 20, 2018
@oandregal
Copy link
Member

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
Copy link
Member

@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:
image
image

(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
Copy link
Contributor Author

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
Copy link
Contributor

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

@jasmussen
Copy link
Contributor Author

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
Copy link
Member

mtias commented Aug 22, 2018

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
Copy link
Contributor Author

jasmussen commented Aug 22, 2018

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

screen shot 2018-08-22 at 13 04 31

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

@mtias
Copy link
Member

mtias commented Aug 22, 2018

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

@folletto
Copy link
Contributor

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
Copy link
Contributor

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

@youknowriad
Copy link
Contributor

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

@jasmussen
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor

closed by #9572

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

10 participants