Devise a mechanism by which the block options menu can scale more elegantly

[jameskoster]

What problem does this address?

We've added a lot of items to the block options menu. It's become a bit unwieldy and it's not uncommon to encounter a scrollbar which buries frequent actions:

https://user-images.githubusercontent.com/846565/226925531-9cabb6d1-49f9-4332-95ab-b2d4efc7fada.mp4

What is your proposed solution?

A flyout has been suggested in https://github.com/WordPress/gutenberg/issues/47464. We can theoretically apply that to some of the actions in this menu to reduce its initial footprint and better organise actions.

The flyout is only one approach, how else can we address this?

[richtabor]

Related in part to https://github.com/WordPress/gutenberg/issues/42203.

A couple top-of-mind thoughts:

• Does "Insert" work better than "Add"?

• "Remove {blockName}" feels a bit obscure. It helped having it in a separate MenuGroup, but I wonder if "Delete" is a better term — without the block name. I don't know that we're adding a lot of value indicating what block is selected within this menu, on this one item.

• Both "Lock / unlock" should probably be capitalized (as is Copy / Paste).

• Should there be a space around the /?

• "Move to" seems the least important one here.

• I like the idea of having the most important/always on every block options into its own MenuGroup, like what I pitched originally in https://github.com/WordPress/gutenberg/issues/42203 — Duplicate, Add/Insert, Copy/Paste, Delete. Then the second MenuGroup is all the additional controls — Group, Ungroup, Lock/Unlock, Create, Move to, Edit as HTML, etc.

• Alignment for the shortcuts/carets/icons is a bit funky. Maybe right align them more, though I know that breaks the convention a bit. Example from MacOS:

  

[jameskoster]

I agree on getting rid of the block name in the remove action. It's very noisy if you selected something with a long name like a template part or reusable block. "Delete" makes sense to me.

"Move to" seems the least important one here.

I know some folks use this a lot so curious to hear more on this point.

I like the idea of having the most important/always on every block options into its own MenuGroup

This would align a bit with the block transform menu so could be a good change.

[jameskoster]

A small update on this one:

• Grouped the most common actions together at the top. I think there may be a case for keeping delete at the bottom because it's so ingrained at this point, but let's discuss.
• Simplified language
• Removed decorative icons. With the addition of chevrons for flyouts (which seem more valuable) these were adding some noise, and I'm not sure they're all that helpful in the first place.
• Group (/Ungroup) now a single item
  • Creating template part / reusable block moved to a 'Sync' flyout

[richtabor]

Do you think we need "selection" in "Group selection" — I'm thinking not. And where would "Edit as HTML" go?

[richtabor]

My one hesitation is moving Insert before/after into a flyout. It makes sense on paper, but subjectively I use "Insert before" likely more often than another other item on the list.

[richtabor]

Also, the separator would be $gray-900, right?

[richtabor]

We also have "Select parent block (blockName)" to account for. I'm thinking it shouldn't displace the other items in the common actions. Perhaps append to the end of the common actions?

[alexstine]

Left some feedback on the linked PR.

• Changing remove to delete makes sense.
• Delete blocks is too trivial for non-sighted users. Sighted users can see what is currently selected in the canvas.
• Up until now, I thought you could only access the block toolbar if one block was currently being edited. I had little idea that the block toolbar was still available to use for multiple blocks.
• Due to how hard it currently is for non-sighted users to tell what is selected outside of the toolbar, it would be nice to provide that context somehow that the toolbar will take action on all selected blocks including X, X, and X.
• This would be where I would highly prefer a right click context menu for these things. It was ultimately shot down for the list view.
• It makes sense to keep delete in the last group at the end of the menu for quick access with up arrow key.

I am not sure this discussion needs to happen over delete blocks or the entire toolbar itself. Likely the toolbar. That way we can provide some type of description on the toolbar to let users know the controls apply to the selected blocks. Might be good for a follow-up PR since all of this is being discussed currently.

[jameskoster]

We also have "Select parent block (blockName)" to account for

Do we still need this? The paren't selector seems like a more convenient affordance, but I'm not familiar with the history.

I use "Insert before" likely more often than another other item on the list

No big deal to keep these top level:

Group 1

• Copy/paste
  • Copy block
  • Copy styles
  • Paste styles
• Duplicate
• Add before
• Add after

Group 2

• Move to
• Lock/Unlock
• Group
• Sync (would become 'Detach blocks from template part' when already synced).
  • Create template part
  • Create reusable block
• Edit as HTML
• Delete

[richtabor]

I'd adapt Group 2 as follows:

• Group
• Lock/Unlock
• Sync (would become 'Detach blocks from template part' when already synced).
• Move to
• Edit as HTML

[richtabor]

It makes sense to keep delete in the last group at the end of the menu for quick access with up arrow key.

We should probably have a divide between it and others then. I don't want it to get lost (though I don't know that three groups is really necessary).

What if it was prioritized over Add before/after, like this:

• Copy/paste
• Duplicate
• Delete
• Add before
• Add after

[alexstine]

Even in native OS menus such as Windows, delete option is always near the bottom.

1. Open file explorer.
2. Right click an item.
3. Notice how bottom to top goes Properties, Delete, etc.

Delete is a destructive action. Nice to have it at the end.

[richtabor]

It's not always last, on MacOS at least — but as long as it's not lost, I'm good. :)

[richtabor]

In all, we're a bit in the weeds—but forward progress; love it.

The big blocker here is the flyout type component. @alexstine what are your thoughts on flyouts (or submenus) in this use case. Do you have examples, or other libraries, that leverage accessible submenus in UI well?

Like the Radix DropdownMenu component for example.

[richtabor]

Do we still need this? The paren't selector seems like a more convenient affordance, but I'm not familiar with the history.

I don't think we do.

[alexstine]

I am not familiar with any 3rd party libraries that have out of the box accessible components. Most React/Vue libraries are junk for accessibility. Any reason we're not going to develop this in wordpress/components?

Happy to check any examples but I will set expectations now.

Thanks.

[richtabor]

Any reason we're not going to develop this in wordpress/components?

Likely will, though I would like to start off with good examples to work from if possible.

[alexstine]

@richtabor I am having a really hard time coming up with any ARIA specifications for flyout menus. If it helps, the flyout menu for Google Drive is perfectly accessible. Other than that, I think we'll have to just see what works. I am kind of interested to see if there are any accessible examples out there but I am coming up empty.

@joedolson You know of any good material on this?

Thanks.

[jameskoster]

I've updated the design in the OP based on discussion, and will mark comments as outdated. Agree the design is in a decent place as a starting point.

The one detail missing is whether or not we still need the Select parent action. I think it predates both List View and the dedicated parent selector affordance, which both feel like more convenient ways to select the direct ancestor, hence the removal. What do y'all think?

[alexstine]

@jameskoster Where is the dedicated select parent located?

[ciampo]

Any reason we're not going to develop this in wordpress/components?

We are indeed looking into adding support for nested dropdown menus, but as @richtabor also explained, it's good to start exploring our usecases and let that help us to make the right decisions.

It's very likely that we'll resort to a third party library, since this pattern is quite complex and difficult to get right, and there's no need for us to reinvent the wheel. Hopefully we'll find a good solution that is accessible, fits our needs, and at the same time works with all the constraints of the editor (the biggest one that comes to mind is syncing position updates across the iframe).

I hope we'll be able to share updates within the upcoming weeks.

[alexstine]

Oh, the iFrame. That will be interesting for sure. Still having a really hard time getting basic functionality to work in it across all screen readers. See #47767 for more context. I urge us all to really take our time in testing. I am a screen reader user and not testing on both platforms came back to haunt me there.

[jameskoster]

@jameskoster Where is the dedicated select parent located?

@alexstine it's the first item in the block toolbar, titled 'Select [block name]'.

[alexstine]

@jameskoster Awesome. No need to keep it in the more menu then.

[richtabor]

We are indeed looking into adding support for nested dropdown menus

Here's another use case for supporting nested dropdowns: https://github.com/WordPress/gutenberg/issues/40208

[richtabor]

@ciampo do we have/need an issue separate for the nested dropdown? And is there an update on that front perhaps? Thanks!

[ciampo]

@ciampo do we have/need an issue separate for the nested dropdown?

We didn't, but I just created one: https://github.com/WordPress/gutenberg/issues/50459

And is there an update on that front perhaps? Thanks!

I plan on releasing a very experimental, initial version of the component in the next days. It will still need tweaking and lots of testing in the editor, but hopefully we'll get there quickly enough

[richtabor]

I plan on releasing a very experimental, initial version of the component in the next days. It will still need tweaking and lots of testing in the editor, but hopefully we'll get there quickly enough

Very cool!