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

Support Navigation and Edit Mode #16500

Merged
merged 29 commits into from
Aug 2, 2019
Merged

Conversation

youknowriad
Copy link
Contributor

closes #11581
This is #5709 take 2

The idea is:

  • using "tabs" navigate between blocks
  • hitting "enter" you enter the "edit" mode (the way it works today)
  • hitting "escape" to get back to navigation mode.

The original PR was abandoned because the keyboard event to enter navigation mode was not caught properly in all screen readers. This is fixed in this PR by using a focused button (the block name/breadcrumb) when in navigation mode.

The breadcrumb still needs to be designed properly (because it's now a button) but the idea is here.
I also removed the breadcrumb "animation" when you hover a block because the button was not showing right after you hit "escape".

@youknowriad youknowriad added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Design Feedback Needs general design feedback. Needs Accessibility Feedback Need input from accessibility labels Jul 10, 2019
@youknowriad youknowriad self-assigned this Jul 10, 2019
@jasmussen
Copy link
Contributor

Hoooly guacamole, it's happening! Here's a quick GIF:

navigation mode

Initial keyboard usage impressions feel great. Fast, fluid, and it feels kind of intuitive too.

Would it be possible to allow the Delete button to delete the focused block? I would love to be able to, in any block, press Escape and then Delete to delete that block.

The focus style should probably also be rather different from both the hover and selected states. It seems like such a focus has more in common with either a multiselected block, or a focused textfield:

Screenshot 2019-07-10 at 13 58 12

Screenshot 2019-07-10 at 13 56 41

@kjellr
Copy link
Contributor

kjellr commented Jul 10, 2019

This is very cool! In my tests, it only appears to work if you start navigating only with the keyboard. Is that right? Or is there another way to activate it? Once I hit enter to edit a block, I can't figure out how to get back into navigation mode. 🤔

Would it be possible to allow the Delete button to delete the focused block? I would love to be able to, in any block, press Escape and then Delete to delete that block.

+1 to this. That would be awesome.

The focus style should probably also be rather different from both the hover and selected states. It seems like such a focus has more in common with either a multiselected block, or a focused textfield:

I wonder if something like this is more appropriate?

Frame 2

It's the same left border we use, but with a blue "active" state. I've also adjusted treatment of the breadcrumb so that it appears like a standard toolbar button.

@youknowriad
Copy link
Contributor Author

@kjellr

This is very cool! In my tests, it only appears to work if you start navigating only with the keyboard. Is that right?

you can hit "Escape" when you're in edit mode to enable "navigation" mode.

@youknowriad
Copy link
Contributor Author

Would it be possible to allow the Delete button to delete the focused block? I would love to be able to, in any block, press Escape and then Delete to delete that block.

This is done.

I also added the is-navigation className to be able to target that state by using .is-selected.is-navigation. I'd appreciate if you have some time to tweak the design accordingly. Designers eyes are the best :P

@kjellr
Copy link
Contributor

kjellr commented Jul 10, 2019

I also added the is-navigation className to be able to target that state by using .is-selected.is-navigation. I'd appreciate if you have some time to tweak the design accordingly. Designers eyes are the best :P

Great! I'll jump in and take a look later today.

@ellatrix
Copy link
Member

How will it be clear what mode you're in? Modes are generally pretty confusing.

hitting "enter" you enter the "edit" mode (the way it works today)

Enter ("return" on a lot of keyboards) traditionally creates a new line. Changing that seems a bit strange.

@kjellr
Copy link
Contributor

kjellr commented Jul 10, 2019

I added some quick styles to match the comp above:

navigation-mode

@ellatrix
Copy link
Member

What if you can also use Tab to escape the mode? As soon as you cross the block boundary, you're back in block navigation mode.

Regarding Enter, one solution could be to also include the insertion points when tabbing through blocks. That way it's easy to navigate around blocks and insert between blocks. Sure it's twice as much to tab through, but way better than it is now.

@youknowriad
Copy link
Contributor Author

In a lot of situations Enter does something different. When you click a button for instance and I feel this is a very similar situation so I don't think in "navigation" mode "Enter" is expected to create a new line. In "edit" mode that's the case though.

@youknowriad
Copy link
Contributor Author

Noting that the "Escape" key now conflicts with the previous expected behavior (show the toolbar). I think the new behavior is better but I thought I'd mention cc @aduth (It's breaking some e2e tests now)

@jasmussen
Copy link
Contributor

It's the same left border we use, but with a blue "active" state. I've also adjusted treatment of the breadcrumb so that it appears like a standard toolbar button.

I wonder if we should just show the same blue all around? This is a focus state, so I feel like it should ambiguate more from the selected state than otherwise.

Here are some other applications that use what can best be described as a navigation mode. MacOS Finder:

finder

It even has the same enter/escape behavior.

Slack:

slack

Worth noting that in slack, you just use the arrowkeys to navigate, and tab to enter buttons of each message, so it isn't a 1:1 comparison. But the visual style distinctly feels "focusy".

@youknowriad youknowriad force-pushed the add/navigation-mode-take-2 branch 2 times, most recently from 736415f to 465a2a9 Compare July 11, 2019 09:24
@youknowriad
Copy link
Contributor Author

Can I have thoughts or a ✅ here?

@ellatrix
Copy link
Member

ellatrix commented Aug 1, 2019

I'll review it again in just a bit.

@afercia
Copy link
Contributor

afercia commented Aug 1, 2019

Thanks everyone for working on this, definitely better than version 1 🙂 I'd like this to be extensively tested by the accessibility team. Given the importance of this new interaction flow, I'd like to not be the only person giving accessibility feedback.

Will propose during tomorrow's weekly accessibility meeting. Of course, everyone is welcome to attend the meeting (Note: meetings happen on the WordPress Slack, registration is required).

Copy link
Member

@ellatrix ellatrix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some minor comments that could be nice to address, but other than that this looks great.
I can't give much accessibility feedback though.

// not already handled by descendant.
onInsertDefaultBlockAfter();
event.preventDefault();
if ( canUseShortcuts && isEditMode ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor: these nested switch/if statements look a bit odd to me. Could they maybe be combined?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No easy way to do it. We could just use if elses?

packages/block-editor/src/components/block-list/block.js Outdated Show resolved Hide resolved
}

componentDidMount() {
window.addEventListener( 'mousedown', this.switchToEditMode );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does it apply to the whole window? If you click inside a block it makes sense to switch to edit mode. If you click outside a block it makes more sense to stay in navigation mode?

packages/block-editor/src/components/writing-flow/index.js Outdated Show resolved Hide resolved
packages/block-editor/src/store/reducer.js Show resolved Hide resolved
@enriquesanchez
Copy link
Contributor

Just tested this (Mac/Firefox 68.0.1) and works like a charm. This is a big improvement IMHO.

🤔 Thought: when in navigation mode, what if we added the ability to move to the sidebar with the right arrow? and then maybe back to the block with the left arrow?

@youknowriad
Copy link
Contributor Author

when in navigation mode, what if we added the ability to move to the sidebar with the right arrow? and then maybe back to the block with the left arrow?

Interesting idea. It would be good to find ways to improve the navigation to that panel. Right arrow to go there seems ok but left arrow to go back might cause issues depending what "control" is focused on the right sidebar. Imagine it's an input for instance.

@afercia
Copy link
Contributor

afercia commented Aug 2, 2019

Worth noting right and left arrow keys wouldn't work with screen readers. Also, when the block is in edit mode and the caret is within an editable field, arrow keys should keep their default behavior (moving through text).

@youknowriad
Copy link
Contributor Author

Ok let's try this, happy to address extra feedback.

@youknowriad youknowriad merged commit 2f757fa into master Aug 2, 2019
@youknowriad youknowriad deleted the add/navigation-mode-take-2 branch August 2, 2019 13:07
@kjellr kjellr added this to the Gutenberg 6.3 milestone Aug 2, 2019
@youknowriad youknowriad mentioned this pull request Aug 19, 2019
22 tasks
gziolo pushed a commit that referenced this pull request Aug 29, 2019
gziolo pushed a commit that referenced this pull request Aug 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Accessibility Feedback Need input from accessibility Needs Design Feedback Needs general design feedback.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Steps to make keyboard navigation usable
8 participants