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

Site Editor: Navigation panel placement #25701

Closed
vindl opened this issue Sep 29, 2020 · 4 comments · Fixed by #25884
Closed

Site Editor: Navigation panel placement #25701

vindl opened this issue Sep 29, 2020 · 4 comments · Fixed by #25884
Assignees

Comments

@vindl
Copy link
Member

vindl commented Sep 29, 2020

As pointed out in #25622 (comment) by @shaunandrews, we should investigate whether it would make sense to render navigation-panel as the first element within the the interface-skeleton, and potentially moving navigation-toggle__button outside of skeleton__header too.

This might help with transition animations, tab ordering, and fixing alignment issues of other elements in the header.

@Copons
Copy link
Contributor

Copons commented Oct 6, 2020

Quoting @shaunandrews' comment for context:

Now that you mention it, I find it strange that the navigation-panel is being rendered inside the skeleton__body; Wouldn't it make more sense to render it above the skeleton__header, as the first element within the the interface-skeleton? Taking this even further, perhaps the navigation-toggle__button doesn't belong in the skeleton__header either. I think moving these components outside the header and body could help with both the transition and an alignment issue that has popped up in #25630.

@jeyip jeyip self-assigned this Oct 6, 2020
@jeyip
Copy link
Contributor

jeyip commented Oct 6, 2020

I think moving these components outside the header and body could help with both the transition and an alignment issue that has popped up in #25630.

Note:
The alignment issues mentioned by Shaun have since been solved by leveraging flex-basis to center the document settings labels in #25630.

Moving the panel and toggle button, however, seems like it's still worth exploring to potentially solve two remaining issues:

1. Unintuitive keyboard navigation (@shaunandrews do we want Shift + Tab to focus the toggle button?)

Shift+Tab from the back button doesn't focus the "Toggle Navigation" button, but the last element of the header toolbar.
This is consistent with the Inserter's behaviour, and it makes sense technically (both navigation and inserter are "physically" rendered at the end of the header), but not so much if one wanted to easily close the sidebar after opening it.

2. Animation issues (@vindl could you confirm this? I'm not seeing syncing issues locally)

The animation of toggle and sidebar slide in are a bit out of sync. It's not that noticeable because of short duration. If we want to match them perfectly we could switch to linear animation, since I don't think we can perfectly match cubic bezier ones in general.

@Copons
Copy link
Contributor

Copons commented Oct 7, 2020

@jeyip

  • The animation issue was caused by the sidebar and toggle button requiring different animations.
    The button had to animate the width from 60 to 300px; the sidebar the translateX from -300px to 0 (or something like that).
    The idea was: let the button animation wait until the sidebar slides in to "join" the button, and then have them slide together. This was probably impossible with Guten's default cubic bezier animation.
    The workaround was to have a linear animation instead, making the delay calculation easy, and removing the concern of adjusting the after-delay curve.
    Maybe if button and sidebar were "together", there would be a way to use one single cubic bezier animation taking care of both.
    Let me also add that imho this is not a big deal. The animation is 0.1s long, so it's not very noticeable anyway.

  • On the other hand, having the sidebar near the button would help us a lot with the keyboard navigation.
    I'm not an a11y expert, but I'd argue that not having to manually adjust the keyboard nav would be a great improvement overall.
    We might not even need to manually move the focus from Toggle to Back to Dashboard on sidebar toggle, but just let the user do it with a simple tab press.
    What I'd love to see is this tab order (in both directions), which I think should happen "for free" if we manage to place the sidebar right in the middle of the Toggle and Inserter buttons 🤔

    • Toggle Sidebar Button
    • Back to Dashboard Button
    • Navigation Menu Items
    • Editor Header Toolbar (starting from Inserter)

@jeyip
Copy link
Contributor

jeyip commented Oct 7, 2020

@Copons Thanks for the context! Much appreciated 🙂 The reasoning makes sense, and I'm currently working on implementing what you're describing in a draft PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants