Enhance Template Inspector

[jameskoster]

It would be nice to:

• Allow $custom template names / descriptions to be edited
• Include revisions (Site Editor: Allow Revisions for the Site Editor #36060)
• Provide ways to delete, revert, etc (Site Editor: add option to disable templates #49640)
• Surface relevant patterns for quick layout switching (Surface related patterns in the template inspector #44582) 🚨
• Migrate all these enhancements to the Template Editor (accessed via Post Editor).

[jameskoster]

I spent a little time exploring this today, here are some thoughts.

One observation is that we have a lot of overlap between the popover that is accessed via the top bar, and the template details in the inspector:

Popover	Inspector

They both display the name, description, and template part areas. It may be worth aligning these features 1:1, so that we can consider removing one or the other in the future.

Custom templates

As for that alignment, here's what I have for custom templates:

Since these templates are user generated, we can display the author along with a link to revisions.

These templates can be deleted, and their name and description can be modified. Here's how the latter might work:

edit-name-description.mp4

Theme / Plugin supplied templates

These templates cannot be renamed, and they cannot be deleted. They can however be reverted back to their original state.

Here we list the Author as the original source (IE the name of the theme or plugin that supplied the template). In addition we display the details of the last edit, plus links to revisions, and to reset the template.

For both types of templates we can re-use the logic created for the "Added by" column in the template list to detail the author.

[shaunandrews]

They both display the name, description, and template part areas. It may be worth aligning these features 1:1, so that we can consider removing one or the other in the future.

I don't see why we'd want to make them exactly the same, and then remove one. Instead, we could just remove one of them now. Or (and this is my preference) we could make them each have their own purpose.

[jameskoster]

We could remove one now, but which one? The popover feels easier to access, and I like the idea of separating document settings from block settings. But this would be a much bigger task in the post editor context as the document settings there are more convoluted, and I'm not so keen on the inconsistency we'd create.

we could make them each have their own purpose

Yes, it's worth exploring. That probably goes beyond the scope of this particular issue, but I think that's probably ok – we can update the issue :)

One thought that comes to mind is placing anything that affects or interacts with the canvas in the sidebar (IE selecting template areas), and more settings / action oriented stuff in the popover. IE:

Did you have any ideas?

[jameskoster]

With #43151 around the corner I figured I'd circle back to this with one eye on template parts as well. Here's a potential next step:

[mtias]

@jameskoster another thing that would be good to start thinking about here is introducing patterns for templates. For example, if you want to switch the archive to have a sidebar or no sidebar, or some other layout starting point.

[jameskoster]

My instinct is that such an interface would present itself:

1. When initially creating the template "Start with a pattern"
2. When all blocks in the template are actively deleted

I'm not sure how it would fit into the Inspector, but there is some conceptual overlap with the template selection flow when editing a post / page, so perhaps we can take inspiration from / align around that.

[mtias]

That seems to exclude the ability to modify the existing design, which should be the most common scenario, not starting from blank.

[jameskoster]

It's always important to consider context in these flows. A theme author building from scratch is unlikely to need this flow all that often. But I agree an end user will use it more frequently.

We should keep the zoomed out view in mind as well. That could be a natural place to surface full-template pattern selection/switching.

[mtias]

Can we do an update here on how close this should or shouldn't follow the details view?

[jameskoster]

The question here is about which model should be adopted for the template detail panel / Inspector relationship.

For pages the details panel is read-only. To edit you have to invoke the full-screen editor. That model could produce something like this for templates:

There's probably an argument to make certain properties editable in the details panel. But following the Pages model seems like a reasonable starting point?

[jameskoster]

cc @WordPress/gutenberg-design for feedback on the mockups in the previous comment.

[jasmussen]

There's probably an argument to make certain properties editable in the details panel. But following the Pages model seems like a reasonable starting point?

I think we discussed elsewhere, that due to the sheer amount of metadata a page can have, including from extensions, we probably don't want to show all of it, or make all of it editable, in the details pages.

One heuristic I found compelling was to potentially surface items as readonly in the details panel, if they are set to non-default values in the editor. E.g. "Private", or "Sticky".

We might even find that we can combine much of the metadata that exist in current status panels into smarter groups/popovers for compression and coherence, like was done with the publish popover in the site editor, that might reduce the footprint of atomically listing out every piece of metadata.

On a separate note, the mockup is a little distracting in that it includes exploratory new componentry with gray backgrounds and a different radius. Such explorations would be great to keep focused, so they don't distract from the meat of the mockup 😅

[jameskoster]

One heuristic I found compelling was to potentially surface items as readonly in the details panel, if they are set to non-default values in the editor. E.g. "Private", or "Sticky".

Yeah I think that is a reasonable rule of thumb, but there will probably be exceptions. For instance the Front Page template – imo we should include the homepage settings regardless of whether they are default or not. There may be scope to concatenate though, so instead of:

Content: Static Page
Page: Welcome

We might try:

Content: Static page: "Welcome"

Of all the other data points in the mockup above, I think the only one we might apply this heuristic to is the status. IE communicate in some other way when the template is disabled, perhaps an icon in the panel header e.g.:

[jasmussen]

Good thoughts, agree there's room for exceptions. And if we can find a rule of thumb for when to make exceptions (like for unique template behaviors like you mentioned, perhaps?) even better.

As for disabled, this seems valid enough to give more prominence than another icon in the title area. Can we make a linebreak after "Displays when the homepage is visited", add a second line that simply says "This template is disabled".

We might even have the "disabled" text have a dashed underline to enable it to be focusable and have a tooltip. I don't actually love this pattern, but it affords further information as to why it's disabled, and what you can do.

[jameskoster]

Yeah that could work, here's an update:

I'm not sure the tooltip is necessary. The only way to disable a template is via the control, so the why is hopefully apparent. There remains a question about whether we need to explain what a template being disabled actually means, we might use a tooltip for that?

[jasmussen]

I think that could be worth a shot, as it seems relatively simple to implement. What do you think?

[richtabor]

There remains a question about whether we need to explain what a template being disabled actually means, we might use a tooltip for that?

Yea perhaps. Do we have extended help tooltips like this yet?

[jasmussen]

Can we shorten the phrase?

[mtias]

What does it mean to edit a disabled template?

[jameskoster]

Templates are enabled on creation, immediately affecting the frontend – this may not be desirable if the site is already live. The most extreme example is Front Page, but templates like Home, Category, and so on can have a big affect too. A disabled state allows folks to work on the template in a pseudo-draft state.

This brings about another question, what is the difference between a 'draft' and a 'disabled' template? Do we need both, or could we treat disabled and draft as the same thing? Is one more intuitive than the other?

[annezazu]

Removing this from the 6.5 board as this wasn't an area of focus for the release.

[mtias]

I think this is mostly accomplished with the ellipsis tools currently exposed. The remaining is superseded by the work on the details panels across post types.