Top Toolbar improvements

[mtias]

The top toolbar has stagnated a bit while the feature set of the editor has evolved. The following design addresses the most pertinent issues including:

1. The lack of parent selector for nested blocks
2. The overall increase in editor UI footprint

Original issue

In particular, the now established block parent selector is missing when top toolbar is enabled, which makes selecting some wrappers particularly challenging (group and gallery, for example). The layout also doesn't feel quite right with the block type not being aligned with the [+], and it becoming somewhat inconvenient on larger screens.

I propose we explore these two changes:

• Add direct parent selector on the left.
• Try center layout and/or floating docked toolbar.

If the docked-floated treatment works, we should have to do anything else for the parent selector. If it doesn't, we'd need some visual treatment between the parent and current block types.

[jasmussen]

Three quick options:

These ideas are mainly based off inital design outlines suggested in #20592, but with an eye towards toolbar-reuse. In the cases above, the main difference in suggestion 1 is the omission of the drag handle, and in images 2 and 3, the color/radius/padding of the toolbar itself.

[jameskoster]

Aligning with the [+] might be safer than aligning to the content due to its variable width. Without that geographical relationship, the floating/docked iteration might not work so well. Option 2 looks quite good to me.

[pablohoneyhoney]

Not sure we are there yet. The first could make sense as a natural relationship to the floating mode. The others have a strange alignment. It could be tested centered, for example, or even all the way to the left.

The uncompleted dividers are perhaps an anomaly from the rest of similar cases in the current language.

[jameskoster]

In terms of the layout, as we explore concepts here it would be good to consider other edit views like focus mode (#37946) and the upcoming zoomed-out view (#41156).

[david-gonzalez-a8c]

Hey folks!

Working on a few concepts for this, will share them shortly :)

[david-gonzalez-a8c]

Hi folks.

Worked on a couple of prototypes, I'm sharing some videos. I think it's important to see this in movement for the fixed effect and because of the change in sizes of the top bar for the child/parent block, as this could bring some visual awkwardness.

Fixed top bar center-aligned:

topbarcentered.mov

Fixed top bar left-aligned:

topbarleft.mov

For this option I've tried other alignments:

But the former felt more balanced.

Also to consider are context like these (which in my view rule out the option of merging the block toolbar and the main Gutenberg top menu):

Here I suggest the top bar if we implement any of these solutions, would "push down" the content to avoid issues like the floating toolbar is causing:
.

Would love to hear everyone's thoughts!

[jameskoster]

Another thing to consider is the interplay between top toolbar and select mode. This doesn't feel right:

[jameskoster]

which in my view rule out the option of merging the block toolbar and the main Gutenberg top menu

I'm curious to hear more of the thinking behind this. Merging seems like the most consistent approach given the array of different views that exist or are in development:

[mtias]

@david-gonzalez-a8c thanks for sharing the mockups. I like the first one, it seems worth trying to see how it feels in practice, as it solves the most salient points right now.

[david-gonzalez-a8c]

I'm curious to hear more of the thinking behind this

Hey @jameskoster. Sorry, that was a little vague on my part! I was referring to efforts in this direction, shared back in #20592.

Not only because of contexts where there's a selector in the main navigation, but also I think it's challenging when it comes to information density.

What you shared makes total sense as a solution to me! I think it's a matter of pros and cons now: I personally like the simplicity of extending the main bar like what you shared and how unambiguous is it, with the floating toolbar it may not be obvious that it will stick to the top until users scroll or play around. But then this is probably more convenient for bigger screens and I think the ability to share the same component in both modes could be valuable.

[jameskoster]

When top toolbar is enabled, the document tools could morph into block tools on selection:

It won't scale down so well to small screens, so we may have to revert to stacking there.

[mtias]

@jameskoster I think this could work, but how would it display the parent block? That's one of the main things this needs to address. Also we might need a way to dismiss the selection and get to the list view / undo redo tools from the toolbar itself. What if the [+] becomes a [<], for example? (or some other collapse icon)

[jameskoster]

What if the [+] becomes a [<], for example? (or some other collapse icon)

Then you wouldn't be able to open the Inserter (keyboard aside) when a block is selected, which could be a can of worms?

I find that clicking in empty space to deselect is a good heuristic, both in the canvas and in empty regions of the UI. There's also the esc behaviour to fall back on.

As for the parent selector, it's probably just an exercise in finding the right separator. Some of the examples already shared could work, here are a few others:

[mtias]

To clarify, the [<] wouldn't unselect a block, just show the higher level tools.

[jameskoster]

Yes I suppose that could work:

toolbars.mp4

There' a question about how you get back to the block toolbar, but clicking the block again seems fairly intuitive.

[jasmussen]

A couple of thoughts for when we're able to pick this back up:

• Latest iteration by looks close in terms of behavior:
  • Back button shows the inserter and other tools again
  • Mini-breadcrumbs for selecting parent block
  • A single unified toolbar
• But it needs probably needs to show the inserter always.
  • This is to consider the flow, where you might click a paragraph inside a group, use breadcrumbs to select the group, and then open the inserter to insert a block there.
  • So we'd show Inserter | Back | Breadcrumbs/Block type | Tools.
  • It doesn’t deselect.
  • The back button could be more visible or obvious, the light gray isn’t clear enough. The solution might be a different icon, the "back" arrow suggests history, but in fact it's a "show more tools" button — simply showing again the undo/redo/list view buttons that were covered by the block toolbar.
• The parent/child relationship could be a bit clearer.
  • Perhaps the separator needs to not be an arrow, maybe a dot or a smaller chevron, and perhaps not light gray.
  • Specifically it could be clearer what semantically is the parent: "this is the anchor, and this is the child". Maybe the parent has the same footprint as the inserter plus, but is dark?
  • Or maybe it has the light gray background, like the current back button has?
• Just like how this top toolbar replaces the shortcuts in the top left when a block is selected, there is a past idea for the inserter to similarly show some commonly used blocks that space. The overlap here is worth keeping in mind: does this toolbar mechanism replace or augment the other idea?

It would be good to bring home this design so we can get it developed. @jameskoster do you have a Figma handy? Would be happy to take a stab at the above.

[jameskoster]

It's a bit messy, but here's the Figma.

[jasmussen]

Took a stab at parsing the feedback above. At face value, it falls apart:

The main issue above is the double close icons in the inserter open + block selected case, as well as the fact that the more buttons have a background, the more clumsy it gets. But the dark color or at least some "anchoring background" on the parent block still feels important to portray the relationship.

So I tried a variation of that which took it in a different direction:

Maybe?

[jasmussen]

Just a quick followup after a slack huddle with Jay, some options on the parent/child unit that can ideally serve as an anchoring element:

I'm not sure either of these entirely work, but there's something about 3 that could be interesting. Sharing in case it inspires ideas.

[mtias]

Can we look at it without the dark toggled state for now? That seems like a separate thing to consider.

[jasmussen]

Perhaps this, then?

[jameskoster]

Here's a version with some animation. I wanted to see if it would help communicate the relationship between document + block tools, and help define the up-arrow icon.

It's a bit tenuous when it comes to the Inspector interactions, but I figured it was worth sharing anyway.

[pablohoneyhoney]

Looking promising to me.

Though I think the shortcuts are adding redundancy and confusion in that context that already serves for two different mental models (full canvas controls + block controls), and it'd be adding yet a third (block addition or shortcuts). Too many elements moving too.

Either we move the shortcuts out of that top bar context and place them below the trigger (+) or they have a very different visual footprint so they actually have a different intent than the other two models.

[jasmussen]

For me the jury's out on whether showing recently used blocks when the inserter is open is actually useful. I think it's good to have a design ready that considers it, but it also seems smart to potentially start without it, like so:

Then we'll know the design scales if we choose to extend it in that direction. And if not, that works too.

[tellthemachines]

Added the "needs a11y feedback" label to make sure we consider all aspects of the desired functionality. For example:

• What happens to the list view button if list view is open when the block is selected? (we may actually be using list view to select the block)
• What relationship does the up arrow have with global tools? E.g. should global tools be a popover-type component? Likewise with down arrow and the block toolbar.

[draganescu]

A problem that needs to be addressed in the design @jasmussen is that, as far as a quick hacky implementation shows, if you have this implemented, using the up arrow have shown the document tools, then opened inserter or list view, then went back to block tools with the button on the right, then you won’t see the block tools dropdowns:

The block switcher is open behind the list view in the screenshot above. Should they just open on top? If so we may have a z-index war with the interface package's panels.

[jasmussen]

using the up arrow have shown the document tools, then opened inserter or list view, then went back to block tools with the button on the right, then you won’t see the block tools dropdowns:

Shouldn't the block switcher should be at a higher level? I see that dropdown as no different than the dropdown that extends from the Preview button.

As far as text labels go, perhaps it's time we create a tracking issue. Spread as feedback across a number of tickets, it's insufficient to just convert aria text to a button text label for this, we need to carefully think about the titles of each of those controls as a starting point.

[aaronrobertshaw]

I've created a tracking issue (#47723) to help coordinate work related to achieving the goals and design outlined here.

[draganescu]

@jasmussen
What happens on small viewports? Nothing or something new?

mobile-top-toolbar.mp4

[jasmussen]

Yes, that's a good question. To help the discussion I'll refer to the top toolbar as two ingredients: document and block controls, which for the purposes of this issue are merged into one on desktop. My instinct for the time being is that on mobile, we separate those two and stack them, block controls below document controls.

I think in general, the mobile toolbar is in due of separate improvements. But even with tweaks there, it's unlikely we'll ever fit block controls and document controls on a single row. In that light, another improvement that's worth revisiting is to see if we can affix the block controls to the top of the mobile device soft-keyboard. Native apps do this very well, but so far this has been very tricky to do in mobile web-apps outside of Chrome on Android. To my understanding, that's due to Android resizing the viewport to fit the available space remaining after the soft keyboard opens, meaning we can just fix the toolbar to the bottom on such touch devices. Meanwhile in some other browsers, like Safari on iOS, the viewport size does not change (last I checked), and instead the soft-keyboard covers part of the page. It's worth looking into this behavior in some codepens, because I believe some of the opportunities here have changed in recent years, it's at least 2 years since I looked at this the last time.

By the way, when we do get to that rabbit hole, this trick might help:

@media (hover: none) {
	...
}