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

Template Navigation: Should open to the "Templates" panel when editing a template #26924

Closed
jameskoster opened this issue Nov 12, 2020 · 7 comments · Fixed by #26964
Closed
Assignees
Labels
[Status] In Progress Tracking issues with work in progress

Comments

@jameskoster
Copy link
Contributor

Upon opening the navigation drawer whilst editing a template you are currently presented with the "Theme" panel:

Screenshot 2020-11-12 at 12 25 17

I think it makes more sense to open this to the "Templates" panel:

Screenshot 2020-11-12 at 12 26 05

@Copons
Copy link
Contributor

Copons commented Nov 12, 2020

@jameskoster Not sure I understand this.

Are you saying that we should open the drawer straight into a nested menu?
I don't really agree with that, it sounds like a confusing anti-pattern. 🤔
It would also complicate the "back to dashboard" button (e.g. should we show two "back" buttons, one to the parent menu, and one to the dashboard?).

On the other hand, given how more important templates are compared to the other element in the navigation's root, I'd argue that we might want to show them in the root as well, instead of nesting.
E.g. of a possible root:

  • < Dashboard
  • TEMPLATES
    • Index
    • Singular
    • All >
    • Pages >
    • Posts >
  • TEMPLATE PARTS
    • header
    • footer
  • CONTENT
    • Pages >
    • Categories >
    • Posts >

(I'd personally nest template parts away, but I'm not exactly sure where to position its parent navigational item ("Template Parts >")

@jameskoster
Copy link
Contributor Author

Nesting Template Parts inside the Templates panel could work. Let's try that?

It is important though to keep in mind that one of the key benefits of using the drilldown pattern is that it can contain many nested levels, and open to contextually relevant panels as required. So I'm not sure I'd say it's an anti pattern.

You can compare the UX to clicking a Settings link in an app on iOS. Doing so often takes you to a nested panel in the Settings app itself.

@Copons
Copy link
Contributor

Copons commented Nov 12, 2020

You can compare the UX to clicking a Settings link in an app on iOS. Doing so often takes you to a nested panel in the Settings app itself.

If I'm not misunderstanding, what you mean is basically what already happens in the Site Editor: if you click "Browse all templates" in the document settings popover, that opens the sidebar directly in the templates menu. (It seems broken right now, but that's unrelated).

I'm not opposed to links outside the sidebar opening the sidebar at a nested menu.
But I don't think the navigation toggle button should do that. Imho that should remain the "main" toggle, opening and closing the sidebar at its root level.

@Addison-Stavlo
Copy link
Contributor

Addison-Stavlo commented Nov 12, 2020

also complicate the "back to dashboard" button

100% - If we are going to start opening the panel to the most contextual menu, we would need the 'back to dashboard' button on every menu. Is that something that would be acceptable? I do understand the argument for opening to the most relevant menu, but 'back to dashboard' definitely needs to be easily found when clicking the toggle button to open the panel.

Nesting Template Parts inside the Templates panel could work. Let's try that?

This seems like a confusing idea. Template parts are not a type or subset of templates and their behavior is quite different both in practical application and potentially in persistence across theme switching. Voting not to conflate these two items together.

(It seems broken right now, but that's unrelated).

Should be fixed now 👍

@jameskoster
Copy link
Contributor Author

jameskoster commented Nov 12, 2020

If we are going to start opening the panel to the most contextual menu, we would need the 'back to dashboard' button on every menu.

I respectfully disagree. This point was raised as a potential issue during the original design process – and I do not entirely disregard it – but during extensive usability testing of this pattern it did not appear to be an issue. May I request that we open up a PR to at least try the concept? :)

I would also add that it has always been the intention that the W button in the content editor would open either the Posts or Pages panel of the navigation, based on what you're editing. So this will not be a unique behaviour.

@Copons
Copy link
Contributor

Copons commented Nov 13, 2020

I respectfully disagree. This point was raised as a potential issue during the original design process – and I do not entirely disregard it – but during extensive usability testing of this pattern it did not appear to be an issue. May I request that we open up a PR to at least try the concept? :)

Sure! It should be a very simple change, so it's not like we'd be wasting hours behind it. 🙂

I've still got a strong opinion about the "back to dashboard" button though.
If the user intention is to leave the editor, I'm pretty sure they would rather just see the back button immediately, than having to hunt for it. 😄
I mean, I'm aware it's just 1 more click, but the flow would be very unclear.

@jameskoster
Copy link
Contributor Author

As I said I do not disregard the concern, but ultimately there are two separate considerations here.

  1. The navigation should open to the contextually relevant panel

I see that being critical to the overall navigation pattern, and a key part of this particular PR.

  1. In the depths of multiple drilldowns, it should be easy to get back to the root panel / dashboard.

That may end up being something we address separately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Status] In Progress Tracking issues with work in progress
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants