G2 block top toolbar

[pablohoneyhoney]

Here a few explorations on how to visualize the top toolbar when active, adapting G2 styles.
Some alternatives permit the top bar to remain clean to potentially absorb more functionality and stay focused.

A (Absorbed by top bar as is today)

B (Creating a second level)

C (Aligned with the top bar UI, 2 options)

D (Horizontal position fixed pointing to the block content area)

E (Centered)

Relevant to:
#20575
#6047
#7485
#3735

[shaunandrews]

Options C, D, and E could cause trouble by obscuring content within the canvas — especially considering full-site editing; ;The toolbar could obscure things like a header, logo, navigation, etc.

I have a slight preference for B, over A; A feels a little too heavy (with extra borders) and isn't realistic on mobile screens. I believe B is how the toolbar works on mobile today.

[shaunandrews]

Related to obscuring content, we could just add extra whitespace at the top of the canvas. This is something I've explore in the context of editing a template, where its likely that a template_part will exist at the top of the canvas.

However, in the context of the Top Toolbar mode, I'd expect the whitespace to always display.

[karmatosed]

My initial preference is absorbing into top navigation, A. In saying that there is something about option C, the first visual. I know in testing there has been almost a 50/50 split in those that want 'by block' and those that want in the toolbar. I almost feel we might need to keep that option in future, or at least phase out gradually. I say this knowing I am suggesting a choice, however, the default might end up being the one people stay with.

I am nodding to your comment about the canvas @shaunandrews and that makes me even more keen on the absorbed option. Whilst the 'bounce in' isn't too dramatic it still feels like it takes me out of the experience and further makes it not feel as would on the front. That might be not an issue though if doesn't fracture the interaction.

[jasmussen]

I love seeing these varying mockups even for things we thought were "stable" and decided upon. A and B is basically what we have today, but with a few visual flourishes perhaps, and after seeing the alternate options, that's still what feels the most right for people who explicitly choose the top toolbar option.

However I like the other options more than I thought I would, and even just exploring them has inspirational value!

[ZebulanStanphill]

With the changes proposed in #20877 in mind, I prefer options C and D.

I don't like the current behavior (A) since it merges one toolbar into the middle of another one, and it makes things like #20877 more difficult to implement.

B feels unnecessarily heavy, and considering @shaunandrews comment, I don't think there's anything to worry about regarding obscuring content.

I'm not too big a fan of E since it makes the position of the block icon jump around as you select different blocks. The point of the "Top toolbar" option is to keep the toolbar in a single place, and so anchoring the left side to a specific point as in C and D seems like the right way to go.

I should note that I never use the "Top toolbar" option, so I'm probably not the best person to ask regarding how it should work, since I prefer the block-anchored toolbars anyway.

[paaljoachim]

Btw here is the top toolbar on a smaller resized desktop screen.

What I like about todays method is that it shows the toolbar below the regular top bar area.
1 row - standard top bar related icons.
2 row - the block toolbar.
It just keeps a clear difference between the two.

[estelaris]

As discussed today in the design triage, the team prefers option B as it seems pretty standard and a method used by other software. The question is if that overflow row will it pre-exist and then be filled out by the icons from the secondary menu? or will it "bounce in" (not preferred method)?

[ZebulanStanphill]

The G2 toolbar is no longer trying to stick out a bit to the left of the current block, and the little black triangle thing is gone, so I think option D is off the table now.

I know I said I prefer option C, but having thought about it more, I've changed my mind: I now prefer option B. It's a lot more clear that the toolbar is stuck to the top in that design than in C, D, or E. The only thing I'm not certain about is the exact horizontal alignment, but that's just a minor detail.

[ZebulanStanphill]

Also, the "heaviness" problem could be solved by just changing the border to look the same as it already does at medium viewport sizes, as seen in @paaljoachim's screenshot.

[OlaIola]

This absorbed current version confused me. I was sure that something is wrong. I was needed to move a block around and make it from a keyboard is very difficult, I was sure that it isn't working also. And with this menu stuck to the top isn't possible to drag block by it.
This menu needs a way to unstick at the same point where it stands.

[ZebulanStanphill]

I've been thinking about this some more, and I think @paaljoachim's mockup is exactly what we should do. Trying to horizontally align the block toolbar to the current block is pointless when you're not going to show it right next to the block, and would be confusing in the context of horizontally-laid-out blocks anyway.

Pinging @afercia to check this out since I don't think he's seen it yet. I think this change could be a benefit to editor a11y, since it would keep the block-level toolbar visually separated from the document-level top bar.

[afercia]

A clearer separation between the document-level toolbar and the block-level toolbar could help all users.

Amongst the option above, B seems to me the most appropriate also because it's basically what we have now for medium/small viewports. I'd leave considerations on whether a split toolbar respect the original intent of the "Top toolbar" to others.

As usual, when it comes to accessibility it's not just a matter of visuals though. Semantics and keyboard interaction are of fundamental importance. Right now, even if the toolbar goes in two lines it's still wrapped in a single element with role=toolbar and aria-orientation=horizontal:

Arrows navigation works for all the buttons within the area highlighted in red in the screenshot above. Which feels weird for keyboard users s they would expect keyboard navigation match the visual order.

Also, if we want a clearer visual separation then we should represent this separation semantically. I'd recommend to separate the two toolbars and wrap them within two elements with role=toolbar. Arrows navigation within the two toolbars should work separately so that the tab order is:

• tab -> document toolbar (one single tab stop)
• tab -> Preview -> tab -> Publish -> tab -> Settings -> More menu
• tab -> block toolbar (one single tab stop)

Having two separate role=toolbar elements would also allow to better label the toolbar. Right now, the single top bar is labelled with aria-label="Document and block tools". With two separate toolbars we could use two labels:

• aria-label="Document tools"
• aria-label="Block tools"

Jumping to the toolbar(s) with Alt+F10
Right now, with the unified toolbar, it is possible to move focus and jump from the selected block to the toolbar by pressing the keys Alt+F10. Note: this key combination comes from the Classic Editor and it was kept because users are familiar with it.

With the unified toolbar this is not a problem because all controls are grouped together. WIth the two split toolbars, where focus should be moved to when pressing Alt+F10? To the document-level toolbar or to the block-level one?

[talldan]

Marking this issue as stale, as it seems quite outdated.

It might be worth making smaller individual actionable issues if there's still anything to do.