There is a short list of theme templates that users are able to create on demand in the Site Editor. Off the top of my head that list is something like:
Front page
Search
Single
Page
404
Archive
The WordPress template hierarchy allows for much more expression than this though, and one of the objectives for 6.0 is to unlock some of that functionality in the UI.
The WordPress template hierarchy in all it’s glory
It’s a tricky interface to design because we have to tackle concepts that I suspect folks contemplate in a subjective manner. For example how do you imagine the sequence for adding a unique template for your “About” page? I can see at least two lines of thought:
I want to create a template for a page, so I’ll look for the pages section, and expect to find my “About” page within that section
I want to create a template for this unique piece of content, so I’ll look for something that enables me to search my whole site
I decided to roughly explore a prototype for each approach. The first makes use of a dedicated “Page” section in the template creation UI where folks would find the primary Page template supplemented by a search input to locate a particular page:
The second prototype presents a single UI for creating specific templates for any use case, not just pages:
A benefit of this second approach is that the primary templates like “Page”, “Post”, “Attachment”, and so on require fewer clicks to create, and those flows feel simpler since you do not need to ponder the specificity angle.
The drawback is that the full specificity gamut is exposed in one UI. As you can see in the video results will include pages, posts, categories, tags, authors… everything. To avoid this being overwhelming some kind of filtering may need to be introduced.
For now these are early concepts and I’m still exploring other potential flows. I’ll likely post these (or some variation of them) in #37407 soon. Feel free to follow along!
Last month I shared some concepts where “global” site elements could be managed in a dedicated area of the UI. In this post I’m expanding and refining those ideas a bit in an effort to explore the broader viability.
If global entities like styles, templates, and navigation menus can be edited in the Site Editor, then it seems feasible that folks may want to manage other parts of their site there as well.
The Site Editor was designed mostly to handle presentational things like posts, styles, and templates, but non-visual entities like users or settings need further consideration. Along with general content management, these are the kinds of things that I concentrated on here.
During these explorations two key UX requirements emerged:
When a management view corresponds with something that could be edited visually, a direct and intuitive pathway between editing and managing should exist
Since the lines between managing and editing can sometimes blur in the site editing context, a distinct visual language should help users orient themselves in the experience.
As is often the case with these things, pictures speak louder than words, so here’s a quick demonstration of how I envisaged a user zooming out of the editing experience to find access to management areas:
The button in the Editor acts as a pathway to the relevant management view. The dark colorisation of the button creates a visual hint towards the nature of the destination and helps to conceptually separate management and editing. Clicking the preview window takes you back into the Editor.
This pattern and design language satisfy the two points outlined above.
Is it a template? Is it a category? No, it… doesn’t matter
As yet we’ve not come up with any elegant pathways to edit entities where content and template overlap.
For example the “Posts page” in WordPress is presented (somewhat misleadingly) as a “page” in the backend, but always redirects to a specific template (not the page template, notably) when viewed on the frontend.
Similarly things like post categories have a content element – you can add a custom description – but right now you can only edit the archive template agnostically. It should be possible for folks to edit and create templates for specific categories without having to understand the technical cruft going on beneath the surface.
We can use the pattern above to contextually surface previews (and therefore editing access) on the relevant screens. As an example, here’s how I might edit a post category:
From this management view it is possible to invoke an instance of the Editor where you can customise the relevant content and template simultaneously. In this environment you might also be able to create a new dedicated template for this particular category.
The Finder-inspired columnar navigation creates the hierarchy of the drilldown pattern we explored in the past, while still providing direct access to the top levels of navigation – something the original drilldown lacked. If this feels like too manycolumns, tabs could be used for filtering instead, and the primary navigation could collapse down to icons as you navigate deeper in to a section:
But this doesn’t scale down quite as well to mobile devices. At this point it’s worth repeating that these are all very rough concepts…
Still, they hold up quite well in other areas of site management, and feel aligned with the idea of WordPress being an operating system for the web.
Media
Making quick edits to media meta is easy to imagine, and this pattern would translate well to other management areas. I can see a lot of value in being able to update things like publish dates, authors, titles, and so on, without launching the “full” editor.
Navigation menus
This hybrid management / preview screen is extremely useful when working with particularly complex menus that include lots of nesting.
Such menus get very tricky to directly manipulate on the canvas, but you can always click the preview to zoom in and do so if desired.
Templates, Styles, and settings
The template management above view is simply a dark-styled interpretation of the one we’ve already implemented for 5.9. A toggle to view the templates in a mosaic configuration (using the preview component) would be a nice enhancement that continues to build on the zooming metaphor.
Likewise, Styles use the same panel that is shipping in 5.9. A mosaic of curated templates in the preview area could provide holistic feedback on style adjustments.
Visual settings like the site icon need to live in the Site editor. Options such as front page settings are also integral to the site editing experience. Folks shouldn’t have to go all the way back to wp-admin to do this. Once again the preview area adds value by clarifying the visual component of these options.
I’m not sure what the next step is here, but I’m hopeful to see some of these items worked on for 6.0. #36667 and #37001 seem like good candidates to explore further.
I shared some designs on make.wordpress.org/design that explore how we might bring some site editing features from Gutenberg to WordPress core for 5.9. Check it out.
The essence of a WordPress theme is: layout (templates) + style = presentation.
The template and global style editing features of the site editor are soon going to provide users with tools to create and manage these elements visually in their WordPress back-end. Community initiatives like the pattern directory present opportunities to enrich these features exponentially.
So the question emerges: If I have the power to tailor the individual components that make up a “theme”, supplemented by curated suggestions from the community while doing so, then what purpose does a single bundle of predefined layouts and styles serve?
I imagine a world where the idea of themes being discrete entities that you install and switch between goes away. Instead, the “default theme” in WordPress is nothing more than a generic version of the templates and styles necessary for the most basic site to operate.
On top of this, flows exist in the UI that enable users to perform bespoke activities, like creating a different layout for a specific post category archive.
In such a flow the user would be presented with contextual layout options that are pulled in directly from the pattern directory. Oh, you want to create a new 404 template? Here are dozens of neat options to choose from, ordered by popularity, rating, you name it. This feels much more powerful than having to accept whatever your theme supplies – especially as it’s unlikely that you chose your theme because of it’s 404 template!
Styles can work in a similar way. Imagine selecting an appealing color palette from a community driven library, directly in the Styles panel of the Editor, and having that cascade across your entire site. Ditto for typography. These tools can all combine in flexible ways to get you 90% of the way toward your desired design destination.
Naturally you can fine tune everything on a per-block basis as required, and even choose to contribute your creations back to the color, type, or layout directories, further enriching those libraries.
On that note, maybe new economies begin to emerge – imagine paying a small tip to install a comprehensive type scheme devised by some A-list design studio. An App Store for style?
No doubt it would still be possible to export your templates and color / type styles as a single theme bundle. But in a world where folks have freedom of expression on a much more granular level, I wonder about the utility of such a package.
When you’re able to easily apply different aspects of design to a single post, a single template, a site header, or even a single block, the concept of a “theme” starts to feel much less monolithic. I’m excited to watch these features interact as they grow and evolve.
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:
Insert the Template Part block
Click “Create new template part” button
Assemble inner blocks
Manually assign the template part to the appropriate area in the “Advanced” panel of the Inspector
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:
Insert “New Header” block
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:
Insert the Template Part block
Click “Choose existing”
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:
Published template parts can be inserted directly in a single click
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:
Swapping a template part
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.
button in the Editor acts as a pathway to the relevant management view. The dark colorisation of the button creates a visual hint towards the nature of the destination and helps to conceptually separate management and editing. Clicking the preview window takes you back into the Editor.
James Koster 