Try adding 'Template Parts' as a tab on the inserter. #22612
Conversation
Addison-Stavlo
added
[Feature] Full Site Editing
[Status] In Progress
|
Size Change: +1.11 kB (0%) Total Size: 1.12 MB
ℹ️ View Unchanged
|
Addison-Stavlo
requested review from
noahtallen,
ockham,
vindl,
MichaelArestad and
epiqueras
Addison-Stavlo
changed the title
Addison-Stavlo
removed
the
[Status] In Progress
Exactly, template parts will go inside groups, covers, grids, columns, etc. They will also contain other template parts. |
I agree. Not only will the difference between the three be confusing to new users opening the inserter, but it seems like a very prominent place to hold something that shouldn't be used often. That is, I feel like template parts should be inserted sparingly where absolutely necessary. Having a panel full of previews like this really makes me feel like I should be using more of them more often. Finding a location that does not over promote their use while still being easily findable/accessible when needed seems like a very difficult challenge.
I also agree with this. |
|
What if we show an extra inserter button only available in the site editor? |
Do you mean making the 'Template Parts' tab not show up in other editors and only appear in the site editor? Or some other 'extra inserter button' ? |
|
An extra inserter button, only present in the site editor, which only shows the template parts tab. |
Gotcha, so we would never have 3 tabs in 1 panel, but would have 2 separate inserters to open. With extra inserter buttons added both: in the top toolbar: as well as in the editor: I feel like this could be just as (or more) confusing than just having the three tabs in the regular inserter. |
That's an interesting an idea worth exploring. We would want to visually differentiate it from the regular inserter. Perhaps even something like what was done for Patterns at first. My concern is that it might not be obvious what it is for or how to use them. What do you think, @enriquesanchez? |
Whether its a tab on the inserter, a second insert button, or a plugin area (or whatever block patterns originally were), It seems like this is going to be the case wherever we add them? It seems like in any case people wont really understand what they are or how to use them, so maybe the issue isn't really with where we are putting them currently (although I do agree we will want the most 'natural' feeling location). Maybe we keep them as a 3rd tab on the inserter, because after all the inserter is for inserting things. On clicking the template part tab, maybe pop up a descriptive modal that won't appear again if a checkbox is selected. Im not a big fan of this specific idea either but 🤷♀️ ideas 😆... it seems like some sort of minimal education is going to need to be a factor wherever they end up? |
|
Yeah, I don't think the third tab is really an issue. And it's one less flow to learn. @mtias, what do you think? |
I think so, yes. It's very hard to add template parts now and it impedes our development/testing flows. I would like us to land this until we figure out a better solution.
Yes. :) And I find this better than having a separate inserter button. @Addison-Stavlo I'm not sure if we should be showing this tab in the post editor, but it might not be that big of an issue, given that it won't be exposed unless the experiment is enabled? I think having a blank template part here might be nice, but that can be handled in a separate PR. |
I guess that depends on what ends up being decided about template parts being usable outside of the site-editor. As it stands now, TPs can be created in the post editor via the placeholder block. Similarly, the post editor has the multi entity save panel integrated into it as well (which I don't think has any use there other than for template parts currently?). If we do decide not to have template parts outside of the site editor, it would definitely make sense to limit this tab from appearing in the other editors. And then it would probably make sense to remove the save panel and placeholder inserter blocks from there as well. Either way, it would be good to have a definitive decision on this, otherwise (for the time being) it makes sense to be in the post editor
That would definitely be a good addition, and would end up in us being able to get rid of the placeholder TP block if desired. |
|
I thought about this a bit more. I also had a chat with Matias about my concerns about moving what we planned to be inside the Template Part block into the sidebar. I think that the sidebar is not the right place for this. The sidebar houses blocks and patterns, which are the basic static building blocks of all documents and are very frequently inserted in all types of post types. Exposing the term there also feels off and too technical. Template Parts are dynamic and very context-specific. I think that the original idea of keeping things in the block makes it simpler to understand that they work differently than blocks and patterns. It also makes it very explicit that they only exist under specific contexts where the block is available. Ideally, the template part block would present three options when inserted:
Transforms should also let you switch between patterns for an existing template part. Designs like these #21080 (comment) will make it easy to present the list of patterns in the block without expanding it and scrolling the block list. I think that a good first step would be to revamp the placeholder to present those three options and have |
|
I'm still thinking about this:
@epiqueras What led you do this conclusion? |
Oo, that is a very interesting suggestion! So our template part flow would still be from inserting the placeholder block, but we would make that block more user friendly and implement some of the functionality found here. This would definitely solve the problem of them being too prominent as with the sidebar tab. They will be a bit more 'hidden', but I think that may be a good thing considering how they are intended to be used. Id be interested to hear about what the design teams think about that idea, and if it makes sense to start moving in that direction. Also, if we decide to go that route, would this PR with the sidebar tab be worth merging temporarily? It could potentially help in the development flow and be reverted once the placeholder is updated. 🤔 |
Even if you were using a grid for the layout of a template part, wouldn't that be a block containing the template part? Technically, there is no limitation on what sorts of blocks can go in the template, so I guess it's a question of why we would want to restrict that extra flexibility that already exists? |
How else would you do something like aligning a sidebar template part against a header template part? |
I don't think it should be too hard to move it to the block placeholder in this PR. Most of the work is already done. |
I agree, most of the work is done already. There might be a couple other things to handle over there beyond some styles and updating e2es that rely on the placeholder. But it shouldn't take a large amount of time respectively. My main concern for 'time' was regarding allowing time for the discussion to happen. Will the majority of design be on board with the idea of doing all of this through the placeholder? Will there be more convincing arguments emerging regarding using an extra inserter or some other proposed solution? I was thinking it might be worth holding off for a bit and focusing on other things while that discussion moves forward, but given that 'most of the work is done' it might makes sense to spin up a working prototype of the placeholder. At the very least it will help fuel the discussions, but I also think using the placeholder this way is a good idea. Il branch off this PR and look at moving things over that way for comparison. |
@noahtallen It would, but it wouldn't need to be something exposed to the user as a standard block. The more we have nested blocks for users to navigate, the more difficult it becomes to navigate. Here's a screenshot from an older mockup that explores grids a little so the block toolbar, etc are inaccurate, but I think it conveys the idea of what could be possible:
It could involve dragging to resize and adding template parts next to other template parts. We would also need document-level controls for keyboard interactions, etc.
There's no technical reason to limit it. There's a usability limitation. We need to find a way to make templates simple enough to build that folks can interact with them and modify them with little trouble. They also need to be flexible enough for complex enterprise sites. I could see the theme being able to add template parts anywhere. As it's an advanced concept to work with template parts inside of other template parts, I am proposing limiting them to the top level of a template in an attempt to keep it as simple as possible.
For now, my design recommendation is this proposal mentioned earlier. That could change based on feedback to it. I do have mockups with a placeholder state for template parts if we do need to go that route. It's effectively a simplified version of this:
Blank would let you choose patterns or blocks to populate it so I would remove that first option from the list. I am okay with this PR merging as is if needed in order for you to be able to test interface interactions similar to the Block Pattern sidebar that existed temporarily. |
|
It's not just about grids, though. Think about separators, static copy/images. Some templates might not even need template parts.
Blank would let you not choose a pattern to start with. It's a shortcut to an empty pattern. |
|
See #22760 for what this would look like from the placeholder block. |
| 'postType', | ||
| 'wp_template_part', | ||
| { | ||
| status: [ 'publish', 'auto-draft' ], |
There was a problem hiding this comment.
Should we add
| status: [ 'publish', 'auto-draft' ], | |
| resolved: true, | |
| status: [ 'publish', 'auto-draft' ], | |
| theme, |
to only show template parts for the current theme? (This would mean we'd need to get theme via the getCurrentThemeSelector.)
There was a problem hiding this comment.
I don't think so. The theme is arbitrary, and user created template parts will be saved under a theme tag that does not match the current theme. Similarly, if we have the template part saved, the theme it originated from shouldn't be a restriction on if we can use it.
There was a problem hiding this comment.
Makes sense. Just to make sure though, could that be a problem when exporting a theme?
There was a problem hiding this comment.
To put on my devil's advocate's hat, I'm not even 100% convinced that we should allow inserting template parts from a different theme TBH 🤔 E.g. I'd expect a theme's header template part to kind of reflect its overall look and feel, so using a different theme's template part might give a rather inconsistent look and feel.
Furthermore, if we make available the template parts from all installed themes, it could lead to an overwhelming number of template parts; and it could be confusing to find the current theme's ones (e.g. to pick the right header). (Clearly, the latter is mitigated by grouping template parts by theme, as this PR does.)
There was a problem hiding this comment.
Template parts from non-active themes will only show if you have customized them.
There was a problem hiding this comment.
I'd expect a theme's header template part to kind of reflect its overall look and feel, so using a different theme's template part might give a rather inconsistent look and feel.
It definitely could, but it allows users to choose from other template parts they have created or customized. If they want to use them over the theme's supplied header template part, they can choose to do so. If the user still feels it doesn't fully match the style, they can be further customized.
Maybe in the future we may need to take steps to make the template part supplied by the current theme to be more prominent (default to the top of the list or something). But since "Template parts from non-active themes will only show if you have customized them.", this may not be necessary.
There was a problem hiding this comment.
Template parts from non-active themes will only show if you have customized them.
That could be confusing enough tho, no?
There was a problem hiding this comment.
That could be confusing enough tho, no?
Good point, it could be confusing between base template parts supplied by the theme vs. ones you have customized from that theme? In which case maybe we could end up presenting it as 'Customized from 'theme-name''. as opposed to just 'theme-name'
There was a problem hiding this comment.
I don't think we should show the non-customized ones if they have a customized counterpart.
EDIT: Alrighty, I guess we'll try the other option instead where it's mostly done in the placeholder block somehow (or time of insertion). Here are some old mockups (ooold) that I can iterate on to get there:
|
|
closing in favor of #22760 |
Description
This is an exploration at inserting template parts via a tab on the inserter. Some designs for this have been suggested, although I am not sure if there is a consensus about whether or not we would want to preview/add Template Parts in this manner. Either way, this gives us a decent idea about how that might look and behave.
More Info:
Screenshots
How has this been tested?
Tested on local docker environment. Tested in the Site Editor as well as in the Post editor (w/ and w/o the FSE experiment enabled).
Types of changes
New feature (non-breaking change which adds functionality)
Checklist: