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

Created on 12 Nov 2020  ยท  7Comments  ยท  Source: WordPress/gutenberg

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

[Feature] Full Site Editing [Status] In Progress

All 7 comments

@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 >")

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.

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.

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 ๐Ÿ‘

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.

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.

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.

Was this page helpful?
0 / 5 - 0 ratings