[Try] Alternate design for block side controls

[chrisvanpatten]

Description

Tries out an alternate design for block side controls, as described in #7182.

How has this been tested?

Hover over the sides of a block to view block controls

Screenshots

Types of changes

This tweaks the UI of the side block controls to add a border to the entire control area, similar to the look of the toolbar.

It should not be merged in this state. This has not been thoroughly tested across browsers (outside Safari and Chrome on macOS), and the CSS changes are… messy. There is also an issue with the overlapping outlines with selected blocks displaying as a darker color (because the borders overlap and are a semi-transparent gray, not fully opaque).

However, it is useful as a quick way to try it out and see how you feel about the design. If folks like it, I can clean up/improve the CSS so it can be merged.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[jasmussen]

I really appreciate all your work lately. It's 🔥 to have design eyes on so many aspects. Thank you for the ticket and the PR.

In this case, I'm not convinced what problem this is trying to solve — one of the key aspects of the side UI is that it is available even without first selecting the block. As such, the consistency with the toolbar is a little lost on me:

Looking at #7182, I feel like it can make a lot of sense to use this "white toolbar background" in nested contexts — we even had this in earlier mockups. I could even be convinced that the side UI needs to have a background when not in a nested context, even though I'm not sure that's a visual improvement as it makes it feel heavier.

If we were to go this route, though, I think we'd want to make some tweaks:

• The hover color as used for the border of the side UI background feels jarring — can we do without that or is that weird?
• The inner padding on the background card makes the side UI taller than a 1 line paragraph — we'd want to try and fit the side UI so it's no larger than one card. This required some tricky math when I worked on it — one paragraph is 56px, so the side UI buttons are 28px to use the maximum amount of space for hit area, while not being larger.
• If we show these buttons on a white card like this, should the buttons themselves have a different treatment than the box shadowed Icon Button treatment they use now? Otherwise it looks like we're just adding additional borders. Perhaps the formatting button treatment could be used here?

CC: @karmatosed for thoughts.

[chrisvanpatten]

Thanks for the feedback @jasmussen!

I could even be convinced that the side UI needs to have a background when not in a nested context, even though I'm not sure that's a visual improvement as it makes it feel heavier.

The only reason I think there's an argument for adding it on all blocks is that it's an easier/more consistent approach toward solving something like #6406.

And also because I just like consistency in general, although I'm not wedded to that :)

The hover color as used for the border of the side UI background feels jarring — can we do without that or is that weird?

Agreed. I don't love it either, but it felt strange to have it not match. I'll post a screenshot though and you can see what you think.

The inner padding on the background card makes the side UI taller than a 1 line paragraph — we'd want to try and fit the side UI so it's no larger than one card. This required some tricky math when I worked on it — one paragraph is 56px, so the side UI buttons are 28px to use the maximum amount of space for hit area, while not being larger.

I thought a lot about this too. Fundamentally I understand, but also it feels like a bit of a losing battle. If themes register a smaller default font size, this becomes unavoidable, unless we consider alternate designs like #6224 (which I really really like, but that also comes with its own set of problems).

I do appreciate that the problem is a bit more obvious with this approach vs the default approach though.

If we show these buttons on a white card like this, should the buttons themselves have a different treatment than the box shadowed Icon Button treatment they use now? Otherwise it looks like we're just adding additional borders. Perhaps the formatting button treatment could be used here?

Agreed completely — they should match the treatment of the formatting button. I didn't address that in the original commits, but absolutely agree and I can work on refining that!

[karmatosed]

I also agree I don't really see the problem this is solving right now. Maybe you can explain a little more there @chrisvanpatten?

I am a little reluctant to have this change just for nesting. It's the same interface we are changing in not a really different context and that feels potentially like it could be an added confusion.

Let's maybe pan out and work out what we're trying to solve and then dig into how this can be consistent? For now, not merging this is the best route. That's not saying we can't dig into things because we totally should.

[chrisvanpatten]

@karmatosed @jasmussen

What I'm trying to address is making block controls more clearly attached to their block, when in a nested context.

We've seen some user confusion in our early tests for a client related to hover controls on blocks that are next to each other.

These controls are really clunky to use, and it's not always clear which controls are connected to which block for some of our non-technical users.

This PR is attempting to solve that problem with a UI that explicitly connects these controls to their block in a visual way.

It also would achieve visual consistency with an existing UI pattern — the toolbar design — rather than the current the pattern of always-visible block button borders, which exists nowhere else in the Gutenberg canvas.

[ZebulanStanphill]

I am not entirely sure how I feel about this design for the side controls, but I do think that having the side controls appear different for hovered blocks versus the selected block (in this case using the same border color as the block) makes a big difference in removing confusion over which block the side controls are attached to.

If this design is not adopted and the floating-button style remains, I think the match-block-border-color thing could still be used there by having the border color of the side control buttons match the color of the block border.

[chrisvanpatten]

FWIW, I am planning to do another pass at this. A bit swamped prepping a site launch for next week, but this is still on my radar :)

[karmatosed]

@chrisvanpatten no problem at all just update when you have time.

[chrisvanpatten]

I still think this has merit, but I'm starting to wonder if #6224 is a better overall solution. Going to comment over there before moving forward again on this…

[karmatosed]

@chrisvanpatten I would like to have us work on #6224 as a starting point. In that case, I hope you are ok me closing this and focusing there.

[chrisvanpatten]

@karmatosed Absolutely — I agree completely! Had planned to close this myself, but you know, life happened 😛