Site Editor: Template Part organisation in the sidebar menu

[jameskoster]

Template parts are currently organised like so in the sidebar menu:

I think it is worth considering whether we need the (potentially confusing) "template part" section. Once the area taxonomy lands for template parts (#28410), we could potentially organise this menu like so:

• Templates
• Headers
• Footers
• Sidebars
• Other

Or even include Headers, Footers, and other template parts alongside existing top-level templates:

Templates

• Index
• Archive
• Page
• Single
• Post templates >
• Headers >
• Footers >
• Sidebars >
• Other >

[javierarce]

Here's my attempt to improve the organization of the sidebar menu.

Following @jameskoster's suggestion, I decided to avoid using the term "template parts" (recently renamed to "areas"). I think that this is more of an internal concept that general users won't really need to know.

That decision comes with a side effect: if everything is a template, and since the current hierarchy of templates is pretty flat (at least in my current understanding derived from reading the WordPress template hierarchy), we'll end up showing a long list of items.

That said, here's a first idea for the template navigation:

Since areas are organized by category and are also smaller template units, I decided to place them on top of the list. I used icons to highlight that they are somehow different from the other type of templates. This also creates a clear distinction that could be useful when scanning the list.

My only concern with this solution is the extra click that users will need to do every time they want to modify a template.

I also explored an alternative version that places the areas and main templates on the top-level… but this idea could be potentially confusing because it implies that "Headers" and "Footers" are not templates.

Shortening the descriptions

While I was working on this ticket, I attempted to make the list of templates more compact by reducing the amount of text that is presented. First, I started by shortening the descriptions by removing the redundant text (eg: instead of saying "Post. Template used to display a single post type" we could just say "Post. Displays a single post type").

A couple of iterations on this could be:

1. Showing the description when the element is selected:

2. Showing an excerpt of the description and reveal the full text when the element is selected:

Here's a short video of how this could play out:

Template.part.navigation.mov

And here's a Figma file with some of my explorations and the prototype.

[jameskoster]

I think the first idea works quite well. I like the icons :) Something about the "Other" label feels at-odds hierarchically with the rest of the templates though. It suggests to me that if the template is not a header, footer, or sidebar, it will be grouped there.

While that is true for template parts, it's not true for the top level templates. Perhaps the top level templates being visible immediately below negates that issue though. What do you think?

It may be too radical, but the following just popped in to my head:

Templates

Layouts >
Headers >
Footers >
Sidebars >
Other >

The "Layouts" panel would contain the post, page, index, 404, archive, etc templates. Perhaps this is too radical :)

My only concern with this solution is the extra click that users will need to do every time they want to modify a template.

That won't be the case once we merge #26964 so that the nav opens to the contextually relevant panel.

---

I appreciate the effort to reduce the footprint of the descriptions, and agree we need to do something there. But since improving the general organisation might take a few iterations I would suggest that we consider unpacking that in a separate issue. What do you think?

[javierarce]

While that is true for template parts, it's not true for the top level templates. Perhaps the top level templates being visible immediately below negates that issue though. What do you think?

Yes, having the "Other" option before the list of templates feels a bit odd. I think it could work in practice because of the use of the icons and the separation from the list of top-level templates… but it's not very elegant.

The "Layouts" panel would contain the post, page, index, 404, archive, etc templates. Perhaps this is too radical :)

Is it too radical though? I like it, it's consistent for example with the language used to explain Gutenberg:

A developer will be able to provide custom blocks that directly render portions of a layout (a three column grid of features, for instance)…

One thing that sets WordPress apart from other systems is that it allows users to create as rich a post layout as they can imagine…

Gutenberg reshapes the editor into a tool that allows users to write rich posts and build beautiful layouts in a few clicks

Also, if we rename the "General templates" and "Unused templates" labels to "General layouts" and "Unused layouts", it will probably remove possible confusions with the "Other" label on the main list (which is still a bit too generic for my taste).

I think this solution is more simple, easier to implement, and could work better than the one I proposed.

Here's how it would look:

That won't be the case once we merge #26964 so that the nav opens to the contextually relevant panel.

True! I should have mentioned that in my comment.

I would suggest that we consider unpacking that in a separate issue. What do you think?

Absolutely, I'll create a new issue for that.

[jameskoster]

Yeah I think this works quite well. It creates a more intuitive distinction between the template types without having to rely on the confusing template/template part naming convention. We could potentially bring the icons back for the top level as well. I wonder how that would look?

I'd be interested to hear @kjellr's thoughts on this from the theme perspective.

[javierarce]

We could potentially bring the icons back for the top level as well. I wonder how that would look?

I think that the highlighted areas of each icon reinforce their name and position… does the icon next to the Layout label give the idea that layouts are "bigger" structures?

[jameskoster]

Closing for now.