Gutenberg: Tools menu styling adjustment suggestions

[karmatosed]

The tools menu could do with a few iterations in current version:

Suggestions:

• Stronger focus state or none on first open as there is a really weird almost layered visual to the menu.
• Spacing between Select and icon

[mapk]

The alignment looks good on my live site.

The icon angles cause a visual weirdness, but everything is aligned correctly. Maybe this is a local build issue, @karmatosed ? I have this problem on my local wp-env build too.

[karmatosed]

@mapk it now is fine for me having reset my entire wp-env. I still find the hover weird though.

[mapk]

Ah ha! I just tested this again in another live site and found the alignment issue. Here's a screenshot:

The Title is also wacky below the popover and not aligning with the content similarly to how our local environments were.

This is a real issue that goes beyond our local environments.

[0aveRyan]

@mapk @karmatosed I'd love to see keyboard shortcuts inline on the modes for clarity like they are in the Main Menu, then use the description to describe more _why_ instead of _how_

Maybe the keyboard shortcut is only shown for the tool(s) available to be toggled to?

[jasmussen]

Hey @0aveRyan — you probably found a regression there, I could swear those keyboard shortcuts used to be visible, or maybe I'm misremembering? I do agree, by the way, they should be present!

The question is how, though — as I recall it, we showed the keyboard shortcut conditionally based on whether it worked or not. For example if you have the edit tool selected, pressing Enter will make a line-break rather than ... well, select the too you already have. Similarly, if you're using the select tool, Enter returns to edit mode, but pressing Escape again doesn't do anything.

So that is to say, I wonder if we should show those keyboard shortcuts depending on which mode you are in.

[0aveRyan]

@jasmussen yep I went back and edited that comment because I realized Enter would create a new empty Paragraph in Edit.

As you indicated, showing keyboard shortcuts only for inactive navigation tools seems a good solution.

EDIT: Also, just poked through history and didn't see shortcuts in the code history, but perhaps they were there in a design mock?

I'd be happy to open a PR once there's some consensus on design refinements

[jasmussen]

Very possibly just a design mock that I'm remembering!

If you'd like to open that PR, I'll help shepard it through. Go forth and conquer!

[0aveRyan]

@jasmussen I've started some of this in #21497, however something I wanted to bring up.

When a Block is selected, using Escape as a keyboard shortcut correctly toggles the Mode. However, if the focused element is the Navigation Tools menu (i.e. a user clicks the Navigation Tools menu and then try the Escape shortcut), the Popup simply closes and the tool doesn't toggle.

Neither of the shortcuts are very "global" shortcuts... if a user is in an input or textarea in the sidebar and types enter, the tool doesn't toggle either.

I like the simplicity and predictability of the shortcuts... I'm not crazy about subsituting in a combo shortcut. But also now wondering whether they should be shown on the menu items. Thoughts?

[jasmussen]

That is a doozy, and this is possibly why we ended up never adding those keyboard shortcuts in the first place. I'm skeptical now also. After all, when you see this:

in that particular moment, ⌘B does indeed make the text bold. Whereas neither enter nor escape work as suggested when you read that text.

Perhaps we should course correct and instead add to this sheet instead?

We could add some items under "Block shortcuts". Or add a new section. What do you think?

[0aveRyan]

@jasmussen Doozy indeed 😎

A few thoughts based on your comments:

• ✅I like adding Enter and Escape to the Block shortcuts in the modal.
• ⚠️I worry about duplicating Escape functionality to both close the Popover and toggle mode... Escape has a long-established UX pattern. It makes sense when in a Block, I don't think it makes sense in the Popover to take both actions.
• ℹ️ Notably, near every icon button in the top left has some form of global or widely-available keyboard trigger. There's the / inserter, Undo, Redo and Block Navigation all can be triggered via keyboard shortcuts. Only the Content Info/Outline lacks a keyboard shortcut (separate issue, but perhaps worth addressing).
• 💡What if we maintain the current Block shortcuts, but add a global keyboard shortcut for cycling through Tools (i.e. Alt + Shift + Tab)? Similar to an OS-level pattern for cycling through open applications, we could have something like alt + tab (Win), cmd + tab (macOS), super + tab (ubuntu). This could trigger a similar modal with Edit, Select and future Tools.
  

Which brings me to...

• _🤔How important is having this toggle in the top toolbar? Does this feature require its' prime real estate -- can it be relocated? Does seeing the current mode persist 100% of the time aid users -- how frequently do we expect them to switch Tools?_ I totally see the value of these tools. Navigation Tools definitely _don't_ belong in the Block Toolbar or Menu, nor the Document Toolbar. But would a global keyboard toggle, perhaps combined with a snackbar or "tool switcher modal" when mode is toggled suffice? Forgive me for playing devil's advocate, I see arguments for both keeping/relocating, but I perhaps lean towards the latter.

[jasmussen]

I worry about duplicating Escape functionality to both close the Popover and toggle mode... Escape has a long-established UX pattern. It makes sense when in a Block, I don't think it makes sense in the Popover to take both actions.

Yep. Let's not do that then. We can always revisit if we come around to it again.

What if we maintain the current Block shortcuts, but add a global keyboard shortcut for cycling through Tools (i.e. Alt + Shift + Tab)? Similar to an OS-level pattern for cycling through open applications, we could have something like alt + tab (Win), cmd + tab (macOS), super + tab (ubuntu). This could trigger a similar modal with Edit, Select and future Tools.

I think this is an idea that could potentially work, but with "only two tools" it feels like a little much at this point, which seques into my answer to your next one ...

How important is having this toggle in the top toolbar?

Key question to ask, and I do feel it is very important. Because it's more than just a tools selector, it is also a _editing mode indicator_, and this aspect is much much more important, and in fact one of the key factors in adding the item there in the first place.

Selection mode, or the select tool, or navigation mode, it's had many names — this is the interface where you can press tab 20 times to select the 20th block in a long post. This is a key affordance for screen readers so as to avoid having to tab through endless tabstops on your journey. It has a number of additional benefits:

• Dig through layer by layer in complex nesting situations, click selects the columns block first, then the column, then contents of the column.
• When editing, press Escape to _select the block_, press Delete to remove it, press Enter to return to editing. A power user flow where you float in and out of these two tools/modes.

Key to this experience, though, is visualizing what's going on, surfacing what happens. To some users they might be confused why suddenly they click to start editing a block and it has a blue border when they expected a caret. They can click again to edit so it will probably not stump them for long. But if they are to ever discover what is actually going on, it's important we surface visually the mode indicator, same as how in Photoshop you might click the canvas to select and instead you paint — "oh, I had the paintbrush selected".

I think your idea of a snackbar notification is an interesting one! And I do applaud you for asking questions that serve to _reduce_ — more often than not I see the inverse. But I feel it does serve an important purpose.

[mapk]

Our conversation here has taken quite the turn. Can we move the requests to separate issues? I'm closing this one out as being fixed. 😄

1. Adding keyboard shortcuts for the Select/Edit tools. (or is this just not possible?)
2. Whether or not to include that tool in the top toolbar.

cc @jasmussen and @0aveRyan.

In response to topic of the issue, I tested it recently and found no more problems.

[jasmussen]

Adding keyboard shortcuts for the Select/Edit tools. (or is this just not possible?)

Given the keyboard shortcuts aren't global, they really only work in context of the cursor, any additional keyboard shortcuts we create aren't going to solve any problems here. But it was good to learn this!