The Template Part block existing in the Site Editor isn’t much more than a proof of concept right now. The recent addition of the area taxonomy has enabled us to present semantic variations for things like headers and footers, but many key flows remain ripe for design optimisation. This week I shared some ideas on how we might make improvements to the template part block in Gutenberg.

Creation

Creating something like a site header is currently a rather arduous process. You must:

1. Insert the Template Part block
2. Click “Create new template part” button
3. Assemble inner blocks
4. Manually assign the template part to the appropriate area in the “Advanced” panel of the Inspector
5. Give the template part a name

For the average user this is way too complex. With template editing functionality coming soon these concepts will be exposed to users in the Editor for the first time ever, and so a need to simplify emerges.

My first idea is to reduce the number of steps required to create something like a header, and augment the process by presenting contextual block patterns in order to help folks get started more quickly. Here’s a video demonstration:

I propose that we re-purpose the “Header” and “Footer” template part variation blocks to serve as pseudo wizards. In doing so we can replace steps 2-4 from above and deliver the following flow:

1. Insert “New Header” block
2. Select a block pattern

In this case we know the user is creating a header so the area can be assigned behind the scenes. Likewise we can automatically apply a more useful name based on this context and ask the user if they’d like to add a custom name after-the-fact.

A “Start blank” affordance is offered in case no suitable block patterns match the needs of the user.

The pattern carousel that appears in the modal is a reused component. The same UX is presented to users when getting started with something like the Query block.

Usage

The process to insert an existing template part is also rather tiresome. Imagine you wanted to insert your “Standard Header” template part in a new page template, right now you have to:

1. Insert the Template Part block
2. Click “Choose existing”
3. Find the template part and insert it

Not only is this flow longer than it needs to be, it also relies on users understanding the technical relationship between template parts and their taxonomic areas. I can’t imagine that many folks looking to insert a site header would expect to do so via the abstract “Template Part” block unless they’re already familiar with WordPress theming paradigms.

The solution here seems fairly simple – expose all published template parts in the various inserters. Here’s a diagram:

This makes the blocks easier to understand based on how they appear in the inserter (categorised and supplemented by the icon) which will be particularly important when viewing search results.

Swapping

One benefit of semantically related template parts is that it enables us to provide a handy swapping mechanism so that users can interchange same-kind layout areas on-the-fly. A the moment this is accessed through the “Replace” button in the template part block toolbar:

I think it’s fair to say that we can make some refinements here!

First of all there is a question to be answered around how useful search will be in this flow. It seems unlikely to me that a site would have so many headers that a search would be required to find the right one. You may argue that there may be enough generic template parts and I would agree with you, but I would also say that it seems unlikely that one would ever need to swap one generic template part for another. Swapping only really seems useful when semantic context is present.

I love reusing flows and components wherever possible, and see no reason not to reuse the modal from before in this flow as well. When you elect to replace a template part, its relatives can be displayed in a modal like so:

The diagram above demonstrates the “Grid” view rather than the “Carousel” view from the video above. Both views will have their merits based on screen size, the particular template part being swapped, and so on. By reusing this component we get access to that affordance “for free”.

---

That’s it for now! This is all very much a work in progress, and you can follow along with progress in this tracking issue on github.