Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tools menu styling adjustment suggestions #19447

Closed
karmatosed opened this issue Jan 6, 2020 · 13 comments
Closed

Tools menu styling adjustment suggestions #19447

karmatosed opened this issue Jan 6, 2020 · 13 comments
Labels
Needs Design Feedback Needs general design feedback.

Comments

@karmatosed
Copy link
Member

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

image

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
@karmatosed karmatosed added the Needs Design Feedback Needs general design feedback. label Jan 6, 2020
@mapk
Copy link
Contributor

mapk commented Jan 7, 2020

The alignment looks good on my live site.

Screen Shot 2020-01-07 at 9 47 25 AM

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
Copy link
Member Author

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

@mapk
Copy link
Contributor

mapk commented Jan 8, 2020

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

Screen Shot 2020-01-08 at 9 37 15 AM

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.

jasmussen added a commit that referenced this issue Mar 3, 2020
jasmussen added a commit that referenced this issue Mar 4, 2020
@0aveRyan
Copy link
Contributor

0aveRyan commented Apr 2, 2020

@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

Screen Shot 2020-04-02 at 4 35 52 PM

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

@jasmussen
Copy link
Contributor

jasmussen commented Apr 3, 2020

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
Copy link
Contributor

0aveRyan commented Apr 3, 2020

@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
Copy link
Contributor

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
Copy link
Contributor

0aveRyan commented Apr 9, 2020

@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
Copy link
Contributor

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:

Screenshot 2020-04-09 at 08 10 03

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?

Screenshot 2020-04-09 at 08 09 24

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

@0aveRyan
Copy link
Contributor

0aveRyan commented Apr 9, 2020

@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.
    Screen Shot 2020-04-09 at 11 11 45 AM

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
Copy link
Contributor

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.

select and edit

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
Copy link
Contributor

mapk commented Apr 14, 2020

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.

Screen Shot 2020-04-13 at 5 00 44 PM

@mapk mapk closed this as completed Apr 14, 2020
@jasmussen
Copy link
Contributor

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Design Feedback Needs general design feedback.
Projects
None yet
Development

No branches or pull requests

4 participants