Gutenberg: Improve usability of parent block selector button

[ZebulanStanphill]

The issue

The parent block selector button is only shown on hover or when you tab backwards into it. This is obviously not ideal for usability, and often, it results in people not even realizing (or just forgetting) it exists in the first place.

Simultaneously, one common issue with nested blocks is making it clear that you're even in a nested block in the first place. When editing Navigation Link blocks, it would be handy if there was a quick and obvious way to get back to the parent Navigation block. The same issue applies to Buttons, Social Icons, and in the future it could apply to the Quote block, if that ever gets updated to use nested blocks.

There's also an issue of what happens when the toolbar goes sticky at the top of the editor. The parent selector button ends up having to overlap the top toolbar, or else it isn't accessible. Previously, the block toolbar had a lower z-index than the top toolbar, but because of the parent-selector, it had to be increased, resulting in this regression when the selected block is scrolled off-screen:

The block toolbar shouldn't be visible at this point, but it has to be in order for the parent-selector to be clickable when the block toolbar is sticking under the top toolbar.

Proposed solution

I propose that the parent block selector button be made always visible when a child block is selected, and that it be shown to the left of the toolbar, rather than above. This would solve all of the aforementioned issues. Here's a rough mockup:

[shaunandrews]

Love this. The lack of a transition would be nice, and its a clearer (and easier to use) indicator of nested blocks.

[mapk]

I agree! It'd be great to see this move to a PR for testing. The visual design works well, so I believe it will come down to how the interaction feels.

[ZebulanStanphill]

Alright, I've created #23800 to implement the new design. The implementation currently does not exactly match what I mocked up, but it's as close as I can get without using convoluted CSS overrides. Perhaps it's already good enough to ship?

[shaunandrews]

After playing with this some more, I'm reconsidering the need to show the parent button all the time. As the nesting of blocks becomes more common, it's likely that every block will display this extra UI. I'm not sure it's worth all the extra weight.

[ZebulanStanphill]

Noting that @mtias made some very good points against the current proposed design in #23800.

Any alternative suggestions are very welcome. Remember, the solution needs to:

• Be accessible and discoverable to all users, whether they use a mouse, keyboard (and/or screen reader), or touchscreen.
• Avoid adding too much extra weight to the toolbar.
• Still be usable when the block toolbar is sticky.
• Make it clear enough that there's a difference between it and the block icon/switcher.
• Not look confusing in situations with small blocks, e.g. the Social Icons block.

[ZebulanStanphill]

Here's an idea... what do you all think of moving the "Select parent" button to the block toolbar's ellipsis menu? That would certainly checks off all the requirements I listed in my previous comment, except possibly the "discoverability" bit. Would it be too hidden if it was in the ellipsis menu?

[mtias]

I think it might be _too_ hidden, but it might still be worth prototyping. If anything, we might still want to have a "Select Parent" there even if there's a shortcut through other means (like the hover or a keyboard shortcut, etc).

This is a very tricky piece of UI. The current situation I think gets a few things right in terms of being somewhat available but never too prominent. From all the explorations I think the ones that will produce the most confusing outcome are the ones that place the parent before the currently selected block in the horizontal toolbar in an always visible state. Considering eventually all blocks will have a parent (post content would be one) it'd seriously hinders the ability to notice what the selected block is, which should be our anchor point.

[ZebulanStanphill]

I've gone ahead and implemented my idea in #23800:

Try it out and let me know what you think! (Preferably on this issue, to keep the design discussion in one place.)

[mtias]

Seeing it now in context with the other actions there's something a bit unnerving with how different it seems :) It'd also make sense to use the icon of the parent block (on the right, like "reusable blocks"). In any case, if we were to try this, I don't think we should remove the current parent-block type effect on the toolbar.

[ZebulanStanphill]

@mtias Added the block icon to the menu item:

I don't think we should remove the current parent-block type effect on the toolbar.

With the menu item being usable by all input methods, perhaps we could lean into the flyout-button being a nice-to-have enhancement designed specifically for mouse users. We could make it invisible to keyboard users (avoiding the confusing UX of having the first tabbable thing in the block toolbar be invisible by default), and simply not worry about touch/mobile usability, since the menu item would be available for those users. How does that sound? @afercia