Scaling the "Add template" menu / flow

[jameskoster]

As we continue to expand the types of templates that can be added in the Site Editor (#37407) an issue with the template menu presents itself:

I have registered a couple of CPTs which make this example particularly egregious, but it's easy to see this menu becoming unwieldy, if it isn't already.

Let's explore how we can better scale this UI, and potentially incorporate the subsequent part of the flow where you choose whether the template is generic or specific.

cc @WordPress/gutenberg-design

[javierarce]

The first idea that occurs to me would be to add a tab menu on top of the list to filter between base and CPT templates.

For the CPT section we could also group items that belong to the same post type under a label.

[jameskoster]

Yeah tabs could work well.

There are a group of 'base' templates that themes will tend to include, e.g. Index, 404, Search, Home, Singular, Archive. I think it makes sense to group these together.

For the remaining templates, arranging by post type is one option, another could be to split by single / archive. This could potentially enable us to reduce noise by removing the (somewhat repetitive) descriptions:

[javierarce]

Much better. I also like the descriptions on top. Maybe we could also add one for the Base category. Something like: "Base templates are used to display main sections of a site, like Search or Archive pages".

[paaljoachim]

I agree! Tabs is an interesting way of splitting up the long list! Looks like this issue is going along a good path!

Regarding descriptions. As in the Base tab area. One can see a description below each option. It would be helpful to continue doing so in the other tab screens as well. As a description for each option can be very helpful to have. A general description in the top is also good to include.

[jameskoster]

Here's a slightly more nuanced take on this:

Templates are split into the following categories: Pages, Features (e.g. Blog), and Advanced.

Pages includes anything singular that doesn't fit strictly into another feature. Page templates themselves are obvious, but here you also find front-page, 404, attachment, and $custom. I included search too, but only because that's a tricky one to fit in... suggestions welcome.

Blog is hopefully self-explanatory. All templates associated with blog posts are found here.

Advanced templates are those that require a decent grasp of the WordPress template hierarchy to interpret. Generally speaking themes include several of these by default, so the list will be short unless you're building a theme from scratch. Others like taxonomy are unlikely to be used all that often.

Categorising templates around features should enable the UI to scale intuitively. For example when you install WooCommerce a 'Store' tab might appear next to 'Blog':

This framework could also be applied as a way of filtering the main templates list. A very rough mockup:

It would be great to hear thoughts and feedback on this approach. I think the 'Advanced' and "feature" sections work fairly well, but expect the 'Pages' section to be a bit controversial. I appreciate that things like 404 and attachment aren't strictly pages, but I suspect this could neatly align with the mental model of users who aren't super-familiar with WordPress' template system. You often hear folks refer to their "404 page", or their "Home page".

[ntsekouras]

Categorising templates around features should enable the UI to scale intuitively. For example when you install WooCommerce a 'Store' tab might appear next to 'Blog':

I'm not sure there is a way to have this information. Most of these menu items are created by fetching the registered taxonomies and post types, which means we rely on the information provided by register_taxonomy and register_post_type.

[jameskoster]

register_taxonomy allows the specification of a post type, so could we use that to group the templates together? 🤔

[jorgefilipecosta]

Hi @jameskoster, The division between single, archive and base seems more concrete, I agree with @ntsekouras that it may be challenging dividing between pages, blog and advances.

register_taxonomy allows the specification of a post type, so could we use that to group the templates together? 🤔

In the case of "Woo", or other e-commerce solutions where although post types and taxonomies may have an association, where would the label "Store" come from? I guess we would need a new API to create tabs in this menu (where one specifies the label of the tab and post types and taxonomies part of that tab)? If we have an API, we also have the risk of lots of plugins using it, and the number of tabs we can have is also limited (but that is not probably an issue on the medium term).

Also, we may have random post types not associated with a taxonomy, or a custom taxonomy I created, that affects posts, pages, and products. If we had the division between pages/blog, advanced where a random post type/taxonomies I created would appear? Would it make sense to have an "Other" tab at the side of pages, and posts?

Should we explore this more nuanced approach that may require an additional API, or should, for now, we go with a "single", "archive", base, and in the future, we check other approaches?

[jameskoster]

The division between single, archive and base seems more concrete

I think this is true for theme developers, but I'm not sure it generally fits with the mental model of those users who are not theme builders, but still want to customise their templates.

Also, I'm not convinced it will scale that well – once you add a few plugins the 'Single' and 'Archive' template lists are going to get quite long.

Edit: Not to mention it also forces us to add more copy so that users can differentiate between taxonomies with duplicate names, e.g. "Category" for posts, and "Category" for products.

where would the label "Store" come from?

I suppose it doesn't have to say "Store". It could just be the post type name – "Product". And in that tab you'd find all templates associated with that post type specifically, including custom taxonomies.

We'd probably need to treat blog posts as a special case though (IE "Blog" tab rather than "Post" tab) because "Post" alone can be mis-interpreted by theme builders to mean posts of any type.

or a custom taxonomy I created, that affects posts, pages, and products

I would be inclined to say that such a template would probably be at home in the 'Advanced' section. But perhaps it could also live in each relevant tab. It might be good to share some examples... generally I'd expect public custom taxonomies to be associated with a single post type.

[jameskoster]

I recently wrote about how we might deliver a more visual template creation experience over here. Hopefully this gives a bit of an insight into why the mechanism shared above could be a good direction for scaling the current menu. Video:

https://user-images.githubusercontent.com/846565/185599910-2f49c633-bd2b-4b8f-be72-bd420bdff2de.mp4

[jorgefilipecosta]

I recently wrote about how we might deliver a more visual template creation experience over here. Hopefully, this gives a bit of an insight into why the mechanism shared above could be a good direction for scaling the current menu. Video:

new-template.mp4

Hi @jameskoster, So should we still try to expand the menu following this proposal:

Or should we try to go directly to this approach https://jameskoster.design/2022/08/11/a-more-visual-template-creation-experience-in-the-wordpress-site-editor/?

I like the visual approach; nice work thinking about it 👍 I wonder where would the different "designs" shown when creating a template for a page come from? (on the image, they seem to be different style variations with different colors, but currently, style variations affect the site and not a template). In most cases, themes, taxonomies, etc., isn't there the risk that we have a single option to select? (the current template shown for that part of the template hierarchy)

[jameskoster]

I wonder where would the different "designs" shown when creating a template for a page come from?

They would come from patterns associated with the template you're creating. So the usefulness of the 'visual approach' mostly reveals itself when many such patterns exist. Otherwise there will only be two options to choose from: next in the hierarchy, or starting blank.

It might be a long wait if we want many patterns to exist before implementing the visual approach. If we were to implement it now, perhaps that would motivate folks to contribute template patterns?

I think ultimately it will come down to how much bandwidth y'all have to work on this. The visual approach would be more sustainable thinking long-term. But simply re-organising the current menu into tabs (at outlined in https://github.com/WordPress/gutenberg/issues/42325#issuecomment-1206455419) seems like a fair interim.

[jameskoster]

I'd love to get some feedback from @WordPress/gutenberg-design on this concept before adding the needs dev label.

There's a (rather messy) Figma file here.

[paaljoachim]

Hey James.

I just checked out the video https://github.com/WordPress/gutenberg/issues/42325#issuecomment-1220515552 and wow that looks nice! The visual approach will be very helpful! I only thing that came to mind is that I wonder if a multi select should be added to where one can select which posts that should have a specific template. Compared to all or just a specific post.

[jameskoster]

That could be nice, but it's a somewhat nuanced flow... would it create a single custom template and apply it to the selected posts, or would it create individual templates (e.g single-post-hello-world) for each? It's a good idea, but perhaps something to consider afterwards as a part of general bulk template creation.

[jasmussen]

Nice work! I think making Add New open a single modal makes a lot of sense, it affords:

• More context
• Emphasis on common actions, de-emphasis on rarer actions (like a single post template)

In the case of a single post template, I would think it so rare that you need to create this, that it's actually important to de-emphasize this one, lest we give it prominence enough that people might think this is a common action. Important to support, of course, but in most cases I would imagine you could and should use the tools available to you in the block editor, to customize your single post, rather than create a separate template for it.

Diving into this screenshot from the Figma:

There are some figma glitches, it looks like, with the all-caps label style applying where Buttons should be. But otherwise there are some modal metrics, that feel off: title aligning with the close button, 1.5px focus style, 2px border radius, the blue of the active tab overlapping with the gray border.

I like the tab style in principle, but I wonder if it's actually the right interface for it. Looking at the single dropdown we have today, I'm not sure it warrants 4 or more tabs. Could subheadings for categoriziation work instead?

On the other hand, I really like the progressive-reveal idea I'm sensing in the creation flow: pick category, pick template with a visual preview, pick whether it applies to all or just one. Can we take that a step further, and hide each progressive step along the way, until its taken? I.e. the following doesn't need to be shown until you've picked a template first:

So perhaps:

• Add new
• I see a list of templates, but no thumbnails are shown until I pick a type
• Under the "Blog" subheading, I pick the "Posts" category, thumbnails appear on the right
• I pick a posts template template based on the visual (perhaps we need a title as well under the preview), and the "Apply template to" picker appears at the bottom,
• "All posts" is chosen by default, but I can pick and search if I like

So a little more MacOS finder like, perhaps. What do you think?

[jameskoster]

Can we take that a step further, and hide each progressive step along the way, until its taken?

Probably worth a try!

[jameskoster]

Here's a rough prototype to test the theory:

https://user-images.githubusercontent.com/846565/197840227-d9618ad4-c382-4da3-af23-ebf087d161f3.mp4

My main concern is that the menu on the left could get very long when you add a few custom post types. We may need to consider collapsible panels or similar.

The jump in height when the modal footer appears is a little awkward too, but not the end of the world. Alternatively the footer could be permanently visible, but the 'Create template' button disabled, and the dropdowns hidden until you choose a template that requires them.

What do you think?

[paaljoachim]

This looks really nice!

My main concern is that the menu on the left could get very long when you add a few custom post types. We may need to consider collapsible panels or similar.

Perhaps one should start out from the start having collapsable panels. Having the collapsable panel Page Templates open. Blog and Advanced closed. User can click Blog or Advanced to see available templates in these sections. This way one can keep a better focus on the area one needs a Template in.

[jasmussen]

The flow feels right, but there's something about the borders and the list on the left/subheadings that feels slightly imbalanced to me. What would it look like with no borders? Or perhaps is there a modal treatment that integrates the modal title with the list on the left, a la macOS?

I also wonder if the icons are helping in the list. Perhaps the icon can be on the left? Or maybe omitted entirely?

Do we need to show titles beneath each template thumbnail?

Nice work!

[jameskoster]

Here's a version with no borders, and collapsible panels:

Removing the borders works well. Collapsing the Blog and Advanced section makes the list more digestible – could be worth a try.

The alignment of text in the sidepanel bugs me a bit, but this is what we get using our existing components out of the box.

Or perhaps is there a modal treatment that integrates the modal title with the list on the left, a la macOS?

It would be useful (and needed for https://github.com/WordPress/gutenberg/issues/43583), but probably not necessary here imo?

https://github.com/WordPress/gutenberg/issues/43583

I don't think so, the template title is the active item in the side panel. Displaying it beneath each thumbnail as well is probably overkill?

Along those lines, one thing the original design didn't account for was the existence of templates like Page and Single. In those cases, if a user selected one of those templates, the only option would be to create templates for specific pages, which would look something like this:

[jasmussen]

That's a vast step forward! Nice! I think the accordions, especially as borderless as this can work well.

There's something about the active state of the template that looks off. Considering we need both focus and active, perhaps active is just a thin black border, allowing focus to be a 1.5px blue one? And finally, the dropdown and "Create template for" looks slightly off — should the page name be bold, and are the metrics inside the dropdown just right? And should we just use regular "Button" text instead of the allcaps label? Getting there!

[jameskoster]

A black outline could work, no strong feelings there, though I would favor consistency.

And should we just use regular "Button" text instead of the allcaps label?

Good point, I was thinking it would be a label but I suppose technically it would be a legend so we can style it however we like.

The radio/dropdown combo may need to be a new component, so we can get the metrics right during its implementation. Alternatively it might be simpler to use existing componentry to begin with, and just reveal the dropdown when the 'specific' radio is selected:

[jasmussen]

I do appreciate the big clickable radio/boxes, but would also agree we can start with less if they turn into a challenge to produce. But mainly it was the use of bold text inside them that felt loud compared to regular text inside buttons.

Nice one, I think this is good to update the ticket with!

[jameskoster]

I updated the OP to include the agreed-upon design, hid outdated discussion, and added the Needs Dev label.

[jorgefilipecosta]

Hi, regarding the options to create a template. @jameskoster said:

They would come from patterns associated with the template you're creating. So the usefulness of the 'visual approach' mostly reveals itself when many such patterns exist. Otherwise, there will only be two options to choose from: next in the hierarchy or starting blank.

The issue is that, as far as I'm aware, there is currently no association between a pattern and a template, something that is a must for this work. So as part of this work, we will need to implement this association. Some options are:

• Use the same approach as template parts, e.g., include in block types something like core/template/single, core/template/404, core/template/home.
  • I don't like this approach. It seems hacky core/template-part is a block type while core/template is not. But it would be the most simple to implement code-wise.
• Have a mapping from categories to templates. e.g., 404 category to 404 template, post category to single template etc.
  • While this approach may work for simple cases, for more complex templates, it may not be easy to get a descriptive category that maps to them. We would also need some API, so third-party plugins can map pattern categories to the templates (post-types, taxonomies, etc.) they create.
• Introduce a new property for patterns e.g: templateTypes which is an array whose values define template slugs where the pattern makes sense e.g.: 404, single-post, home, page, archive, single-product.
  • This is my preferred approach, and I think it is the more coherent with what we have. postTypes allows one to have a start post modal with patterns for the content of a post. templeteTypes would allow a similar modal to create a template. It is also the more versatile a pattern just specifies an exhaustive list of templates where it makes sense there is no mapping and not anything "smart"/"unexpected" going on. It is the one that requires more code to implement. We will need to expand pattern registration APIs, rest APIs, etc.

My plan is to follow option three and a templateTypes property.

So the work is going to start with two PRs in parallel:

• Backend addition of templateTypes.
• UI work where we have the new modal, for now, only two start options will be shown totally blank and the current template of the hierarchy (we need a way to force start blank now that we use fallback every time).

When both PRs are discussed, approved, and merged, we will have the third PR gluing both together and showing the patterns as start options.

[jameskoster]

That sounds like a good plan to me. Though I would say the pattern <> template association shouldn't be a blocker to merging the modal with the two start options. The visual preview therein still feels like an enhancement to me.

I don't know if it affects your intentions, but one thing to keep in mind is that it might be nice for the pattern directory on wp.org to enable folks to browse patterns by template.

[jorgefilipecosta]

Closing as it seems scaling add template is not an issue anymore.