Add new Template modal

[mtias]

This issue goes over design improvements to be done on the "new template" modal that lists all the available theme hierarchy templates and custom templates.

It doesn't include the work done on "zoomed out" and sidebar details in the frame mode, which is tracked separately in #50739.

[tomxygen]

Currently, when creating a new template (page, article, etc), you have the option to choose between applying it to all items or to a specific item.
However, it's not clear that if I choose to apply it to a specific item, then I can't reuse it later for other items, because it doesn't appear in the template selection when writing a new article/page.
To achieve this, one needs to create a custom template, which isn't very convenient since you start building from scratch and you don't have a pre-made template.

If I want to build a template for my posts, I click on the "+" and I get the following options:

I would click on "Single: post" because it says exactly what I'm looking for: a post!
Instead, I wouldn't go for a custom template because "custom" may be something I design from scratch which isn't part of the well known templates like Pages, Posts, WooCommerce Products, etc.

My proposal solution is to allow users to apply templates to specific items (and not just one item or all items).
I've made a mockup comparing the current implementation (on the left) and my proposal (on the right).

This message is the summary of this discussion #50415 with @jasmussen @carolinan @jameskoster

[jameskoster]

Turns out this was a mis-interpretation on my part. This issue is just about polishing the current modal, rather than moving the creation flow to the sidebar.

OP

Like https://github.com//issues/48456, we may need an "iteration 1" that concentrates on moving the add template flow to the sidebar, and circle back to incorporating the patterns-as-sections work later.

Here's a design that can potentially serve as that first iteration:

add-template.mp4

The first control determines the template type. On a fresh install this would just be blog or page hence the segmented control, but it can expand to include things like Store as you add plugins (would probably need to transform to a dropdown).

This allows for some more natural language in the subsequent controls, where the user is able to add definition to the scope. To begin with it will likely be simplest to replicate the current functionality, but the "Choose a page" control can easily be expanded in the future to account for the "Selected pages" as described by @tomxygen.

Finally the user can select a starting pattern, contextual to the template they're creating.

[carolinan]

What is a blog template? It is unclear, it is not a term currently used or established?

[carolinan]

I still think that is more confusing than the current ui. What if you need a custom template that works with both pages and posts and custom post types? Neither pages or posts would really match.

[richtabor]

I'm not quite following as well. I think it's fine to leave as a modal for the time being and polish on that front (unless I'm missing something)?

Re the template type control, I think having all the options in the grid (i.e. the current modal) is a bit easier to distill - along with the step approach in the modal.

Flow wise, it's a bit confusing to create a template then assign it to an already created page right off. At what point is this just a page creation flow vs. a site template flow?

I'd expect to be able to create page templates that I can assign later when publishing pages—or assign replace my existing page template with this new one—rather than assign already created pages to use the new template.

[carolinan]

What about naming the tabs "Site" and "Custom" (or site templates and custom templates ).

Site templates would be created, not "applied". These are all the structural templates that can not be assigned to a post or page in the block editor.

"Apply to" would be the same as "assign" and only list pages, posts, and supported CPT, and assigning would be optional.
Because users have reported difficulties, these would always be available for more than one item (they would not follow the template hierarchy with the post type item and post title slug)

[mtias]

I'm updating this and #48456 to split the moment of creation (quick modal) from the patterns step (editing) so we can better focus the design and implementation work.

[SaxonF]

What's the main benefit of creating a template specifically for a post/page vs just creating a custom template and applying to the post/page? I think the ideal flow would actually start in the post/page itself vs the templates screen.

[SaxonF]

So I spent a bit of time playing with this today and have a few thoughts.

• With the command center out, could we start to make use of it (or a modal experience that mimics it) for actions like creating templates, pages etc? The + button in templates would just open the create a template command.
• With this work complete we are starting to treat these "site" templates as pages. The pages (like category) can be accessed whether they have a specific template applied to them or not, so I don't like our current terminology which suggests they don't exist. e.g. "Displays a single author post archive". I like framing the create template action as "applying" to a page/post if you are ready to do so.
• I really dislike that we rely so heavily on long descriptions to try and explain the complexities of the template hierarchy. Can we get around that by adding a bit more context (e.g. page url or number of pages) and being smarter about what we suggest? Do we have to use the name of the template? For example, if the site is set to display a static page and it doesn't have a home or front page template, can we just show the names of the two static pages instead and work out which template to create?
• In future, I expect the majority of template creation to actually occur in the context of whatever you are editing. e.g. In site editor click on blog -> categories -> my category -> edit template -> "change for all categories or just this one?"

create-template.mp4

[jameskoster]

Connecting the command center to the add-template modal makes a ton of sense to me 👍

can we just show the names of the two static pages instead and work out which template to create?

You're essentially suggesting that the home template name be dynamic, based on the title of the Posts Page. This makes most sense from a site builder perspective, but might be less useful for theme developers who:

1. Will be more familiar with the technical template names.
2. May want to create certain templates regardless of homepage settings.

On a similar train of thought – how would you represent templates like taxonomy, index, date, singular in this framework?

I think it's worth continuing to explore this concept. But there's probably value in refining the appearance of what we have for 6.3 as well. There may even be a middle ground that better covers both technical / non-technical users.

[jameskoster]

@SaxonF okay I thought about it some more, and I think this can work with a couple of minor alterations :)

• Instead of using the page name for the front-page/home templates we can call them something like "homepage" and "blog page" respectively. This should still be intuitive enough (especially with the url hint), and better handles the static homepage scenario, where front-page and the page it references remain discrete.
• We should check with theme authors whether it would be necessary to include the technical template names anywhere, maybe in the details panel.
• Less important, but I'd consider grouping default/specific items together. IE 'Choose a page' immediately follows 'Pages'.

On a similar train of thought – how would you represent templates like taxonomy, index, date, singular in this framework?

Answering my own question, I went ahead and mocked up every single template so that we might identify any issues with this format and tweak accordingly:

To clarify: a user would never see a list this long, unless they were building a theme entirely from scratch. Most of the time templates will be hidden, either because the active theme already includes them, or because we've deemed them too advanced to include so prominently in the UI. singular and single are examples of hidden templates, and I think we should consider hiding taxonomy too, if no custom taxonomies are present.

Most of the time folks would see something like this:

---

It goes without saying that renaming all the templates is a pretty big deal, so we'll need a lot of positive feedback and potentially some user testing before fully committing.

Polishing the current modal still feels like a worthwhile endeavour.

[mtias]

This is done and implemented. There are some good design ideas to continue to refine that we should move to follow ups. Thanks for all the work!