A number of recent developments in the block editor present opportunities to refine the overall flow. Let’s take a look.
Two steps forwards, one step backwards
Originally, the number of templates a user could add was very short, and defined by a static list in the codebase.
But thanks to the hard work done in #41875 folks are now able to add a plethora of templates, for all kinds of contexts.
Consequently we run into scalability issues with the existing UI. The list below is much too long, noisy, and many of the template names make them tricky to interpret.
Another problem was that until recently new templates were created blank, and users had to compose from scratch every time. Not only was this a time-suck / steep learning curve, it also meant that there was no way for us to programatically offer a preview of what the template would look like before it was created.
But since #42520 was merged this is no longer the case – new templates will use the closest relation in the hierarchy as a base – no more blank templates 🎉
While this is certainly something to celebrate, we can deliver a much richer experience. In #40034 we implemented a feature that presents ‘full page’ block patterns whenever an author drafts a new page. We can use the same concept for template creation as well. Instead of using a simple fallback, why not offer that fallback amongst other options, and present a variety of starting points when during template creation?
Stirring the pot
If we combine the issues above into a recipe, what would the outcome look like? Let’s explore.
Instead of a simple list of menu items, we could display a modal containing a grid of thumbnail previews. From here the user can choose the most visually appealing starting point from which to create their template:
This already feels more engaging, and dare I say inline with what you might expect when creating something so intrinsically linked to website display.
To address the scaling issue, the monolithic list of templates is replaced with collections which are accessed via the tabs at the top of the modal. Hopefully these are self-explanatory but to clarify:
- ‘Pages’ is a core collection and includes templates like Front Page, 404, Page.
- ‘Blog’ is another core collection containing all templates relating to the blog; Single Post, Category, Tag, Author, etc.
- ‘Products’ is a collection added by a plugin e.g. WooCommerce. It contains all templates relating to a specific post type, in this case
product. Other plugins could add collections in the same way.
- Finally, ‘Advanced’ is a group of templates that are generally bundled in theme packages, and trickier to interpret. Things like Index, Singular, and Taxonomy are found here.
Side note: The collection metaphor is neat because it could easily pave the way for an intuitive post type creation UI in the future. Imagine having an option to create a ‘Project’ post type, after-which you find all the relevant templates neatly grouped together. You can even conceive of WordPress instances that are Page-centric, and blog functionality is added separately. Achieving such things currently is a convoluted process involving custom code or third party plugins.
The list of templates within a chosen collection appear in the panel on the left. Selecting one of these reveals the options associated with it on the right. From there it’s just a case of selecting the template, and in some cases whether it should be a generic template for all entities, or applied to one specific entry.
Here’s a short video demonstrating the entire end-to-end flow, if you were to create a new template for a specific post.
Note how the thumbnails refresh upon selection of a specific entity. By loading the chosen content we can offer an exact preview and help users make a confident, well-informed decision.
That’s it for the moment. This mockup is just a rough amalgamation of several ideas and features floating around right now. It may come to nothing, or we might go in a different direction entirely. In any case, it was fun to explore.