Move the button to switch to the block inspector to the block toolbar

[youknowriad]

Refs #13663

This PR moves the button to open the block inspector and navigate focus to it to the block toolbar instead of the block settings menu.

[jasmussen]

Thanks for trying this. Here's master:

Here's this branch:

I do like that the button becomes even more visible. And to my surprise, it looks like at actually still fits on mobile:

I think the next thing to discuss before taking this too much further, is what actually happens when you press this?

Right now the behavior is largely the same as pressing the button in the top toolbar. It just toggles the sidebar. But with the button being in the toolbar, this feels even weirder than it does when the option is only in the dropdown menu. Particularly, when the sidebar is already opened, it feels completely counter-intuitive that clicking that cog hides the sidebar. This is something we need to figure out.

The minimum thing we could do to make that better would be to show the cog as "pressed", i.e. with a dark background. But this assumes we want to keep the behavior as simply being a toggle, which honestly doesn't make a lot of sense to me in the block toolbar.

Here's an idea, it may be bad, but bear with me:

• The sidebar can be pinned just like an extension sidebar.
• If the sidebar is pinned, there's a cog in the top toolbar, just like extensions.
• If the sidebar is unpinned, there's no cog in the top toolbar, but there IS one in the block toolbar.
• If the sidebar is unpinned, opening the sidebar is a modal operation.

[gziolo]

Some feedback from my quick tests. It doesn't mean I don't like those explorations. I love them ❤️ I wouldn't even bother to give it a spin otherwise :)

Unified toolbar gets also tricky as you now have two cogs in the header:

(this switch to draft issue 🙈 )

Another issue I observe is that the block toolbar moves to the left when clicking cog and sidebar gets opened (this is expected as it takes some space from the canvas).

[chrisvanpatten]

I haven't actually built/tested myself so take this with a grain of salt ;-) Overall I really like this exploration though!

Right now the behavior is largely the same as pressing the button in the top toolbar. It just toggles the sidebar. But with the button being in the toolbar, this feels even weirder than it does when the option is only in the dropdown menu. Particularly, when the sidebar is already opened, it feels completely counter-intuitive that clicking that cog hides the sidebar. This is something we need to figure out.

...

The minimum thing we could do to make that better would be to show the cog as "pressed", i.e. with a dark background. But this assumes we want to keep the behavior as simply being a toggle, which honestly doesn't make a lot of sense to me in the block toolbar.

I agree with @jasmussen here — it feels strange that this new button toggles but doesn't actually reflect the toggle state (like bold/italic/etc. do)

I like the idea of treating the block sidebar and pinning in a similar way to the other sidebars. I think it's definitely worth exploring. To go a step further, what if the document sidebar is separated as well so it can be pinned independently too?

I could see the "modal" display of the sidebars especially useful as things move toward front-end editing too.

[alexislloyd]

@jasmussen I really like the cog in the toolbar! It makes the sidebar (which is incredibly useful) way more discoverable. I don't actually find it weird that it opens the coplanar side sheet, as the side sheet a) gives contextual tools and b) the settings icon is basically the user saying "I don't see what I need in the toolbar here, take me somewhere with more options" and it fulfills that need well.

When you say a modal sidebar, do you mean like the way Material defines modal and coplanar sheets here: https://material.io/design/components/sheets-side.html? It would be great to see those two options mocked up side-by-side. I suspect the modal sidebar a) might make the interface feel busier, b)might cover the block you are trying to edit, thereby preventing you from seeing the results of your changes, and c) it also introduces an extra step for people who want to keep the sidebar open. For all those reasons, I'd be inclined to keep it coplanar.

[jasmussen]

Great thoughts all, so delightful to see.

When you say a modal sidebar, do you mean like the way Material defines modal and coplanar sheets here: https://material.io/design/components/sheets-side.html? It would be great to see those two options mocked up side-by-side. I suspect the modal sidebar a) might make the interface feel busier, b)might cover the block you are trying to edit, thereby preventing you from seeing the results of your changes, and c) it also introduces an extra step for people who want to keep the sidebar open. For all those reasons, I'd be inclined to keep it coplanar.

Those patterns, yes, are very much representative of what I'm referring to here. To keep it simple, what I'm suggesting is both, essentially:

1. If the inspector is not pinned, then the cog opens the inspector as a dialog, with modal operation, meaning focus is captured until you explicitly exit the modal and close the dialog. This could mitigate the accessibility challenge that it can be to move focus from the block to the inspector and back again, using only the keyboard.
2. If the inspector is pinned, then it is coplanar — basically what we have today, but focus is not captured, which means you either need to know the region hopping shortcut (Ctrl + [button below the Escape key]) to navigate to the inspector and back, or you'd have to press Tab a ton of times.

I completely agree with your assessments, that the primary benefit of the coplanar inspector is that you can see the effect of a transformation instantly. This is already useful when you're changing the font-size. This is why I would not suggest us removing the coplanar behavior, even if the modal behavior also became a thing. So in a way, the modal behavior would primarily be to offer a simpler advanced block settings interaction for users who aren't aware of the keyboard shortcuts, or simply users that prefer the sidebar to not be on the right for a wider writing space (say a small laptop).

At the same time I strongly agree with your meta-point, that if we can avoid creating new features (and therefore complexity, in this case of the pinning behavior), then that is better overall for usability. To that point, it's definitely best to have only the coplanar behavior, and not add modal behavior optionally on top of that.

But if we are to keep that, then we'll want to find a different way for users to more easily navigate from block to sidebar and back again. I suspect #13688 can play a big role there. But additionally, it feels as though we really need to figure out exactly what pressing the cog in the block toolbar does — because it feels really weird to click it, expecting advanced settings to be the next thing you configure, and all it does is close the sidebar.

[alexislloyd]

So it seems like there are three problems to solve:

1. Make the sidebar more discoverable — solved by exposing the cog in the toolbar!
2. Make it easier to keyboard navigate into the sidebar and bak to the block
3. Create a more consistent / better UI pattern for closing the sidebar

[afercia]

One more problem: the more the toolbar is wide, the more the "Add block" button between blocks is hidden. In the screenshot below, how it looks like when tabbing with the keyboard:

I think there is (or was) an issue about this?

[ZebulanStanphill]

@afercia I made #13571 proposing a solution to this and various other block appender and sibling inserter usability/accessibility issues.

[afercia]

@ZebulanStanphill yep, I'd totally second the "in-between inserter" (or whatever it's called now) should be after the block content. From a logical flow and content linearization perspective, it doesn't really make sense it's placed before the block content.

[afercia]

Tested and thought a bit about it, I'd like to share some considerations. I'd agree this change would help sidebar discoverability and it's nice to see this exploration.

However, while the two ellipsis icons are a pre-existing issue, there are now also two cog icons. Maybe it's a bit too much and potentially confusing, especially with the toolbar at the top as mentioned by @gziolo:

The cog button should indicate its pressed state, similarly to the other cog:

But then, not sure the visual effect would be so pleasant.

The classic block would need some adjustment for the buttons placement:

Accessibility:

As @alexislloyd summarized, the main goal is finding a way to make keyboard navigation to the sidebar easier.

I'd tend to think we should try to simplify instead of introducing complexity. The proposal of differentiating the behavior depending on the pinned state of the sidebar introduces complexity and I'm not sure it would help users.

Material can be a precious source of inspiration but its pattern are mainly designed for mobile applications. Whether it's a "coplanar side sheet" or a "modal side sheet", there's nothing specified in Material about the expected keyboard interaction. Nothing at all. Material is not designed with accessibility in mind, we should all be well aware of this when borrowing from it.

Also, although the current control is buried into the dropdown menu, this PR removes a control that has a clear textual label:

in favor of an icon-only control. In the Gutenberg accessibility report, the accessibility team pointed out icon-only controls are an accessibility anti-pattern and their usage should be limited as much as possible.

We shouldn't assume users who open the sidebar also want to move focus to it. That would be an assumption on a specific workflow and an unexpected change of context.

Logical flow and linearization of content: we should try to think at the overall interaction with a block. Very roughly:

• write something / insert something in a block
• only after there is some content, users may need to access additional settings in the inspector
• conceptually, the inspector belongs to the block: it's an "extension" of the block
• however, the inspector is actually separated, disconnected, from the block also visually
• for ideal accessibility, the inspector should be placed immediately after each block in the DOM order: this way users would be able to access it in the most native, intuitive, way: just tabbing once
• the DOM order should match the visual order
• an accessible, inclusive, design should have considered this but, alas, the design placed the inspector into the sidebar since the very beginning of the project
• I'd really appreciate everyone to keep their mind open to changes to the Gutenberg design principles when some of these principles proved to be not ideal for users
• otherwise, all the possible explorations (skip links, modal behavior, etc.) are just workarounds and, by their own every nature, not ideal

I realize these are general considerations that don't offer concrete solutions, sorry for that. In short: would it be possible to explore a completely new placement of the inspector?

[ZebulanStanphill]

Here are some mockups of what the inspector could look like below a block. (I'm also putting the block toolbar and movement controls below the block for similar accessibility reasons.)

Inspector (advanced settings) closed:

|.............................................................................................|
|.............................................................................................|
|.............................................................................................|
|.............................................................................................|
|.............................................................................................|
|.............................................................................................|
| ¶ ⯆ | ≡ ≡ ≡ | B I 🔗 ABC |___________________________|
| ⛭ Advanced Settings | ˄ ⣿ ⌄ | ⋮ More Options |

---

Inspector open:
|.............................................................................................|
|.............................................................................................|
|.............................................................................................|
|.............................................................................................|
|.............................................................................................|
|.............................................................................................|
| ¶ ⯆ | ≡ ≡ ≡ | B I 🔗 ABC |___________________________|
| ⛭ Advanced Settings | ˄ ⣿ ⌄ | ⋮ More Options |
| Text settings.....................................................................˄.|
| Text size................................................................................|
| [Custom] ------------------o------------ [24]px.............................|
| Color settings..................................................................⌄.|
| Advanced.........................................................................⌄.|

[youknowriad]

I'm closing this for now as there's no consensus, happy to reconsider after this gets discussed properly.