Inserting existing saved template parts. #21218
Comments
The Block Inserter feels like the right place. They can be grouped as template-parts and only available during the template building/editing mode. |
|
This issue was meant to cover part of this: #19254 |
|
I have been trying to find a good way to add existing or new template areas (parts) into a template that uses familiar patterns (they're all just blocks). After seeing the work done on the inserter, I decided to see how that could look in the context of adding existing blocks. Inserting existing template areasTry out the Figma prototype!
Screenshots
Notes
|
MichaelArestad
added
Needs Design Feedback
|
This feels great @MichaelArestad! Moving here some of my feedback from Slack for posterity:
|
|
@MichaelArestad, I like how this follows the new Inserter UX. It is so important to have ONE unified way in which the user can add things to their document. I've noticed while testing other full site editors that when the interface changes on how to insert blocks, it gets very confusing for me and I'm left with trying to figure out where I saw a particular interface element before. So good work here! 😍
|
Addison-Stavlo
changed the title
|
The template part placeholder now inserts saved template parts as of #21766. For clarity, I renamed this issue to 'Inserting saved template parts' (and updated the initial post), so we can continue sharing and discussing these design iterations. Thanks all! |
|
@MichaelArestad In the prototype, how does the editor know that the header template part should be inserted at the top (and just below the current header template part)? |
@enriquesanchez Good question. Wasn't intended to operate any differently than any other block. I didn't add a cursor there in figma, but that's where the cursor would have been. In other words, if the cursor wasn't at the top, the block would have been added at the bottom. |
|
Recently, @MichaelArestad proposed the idea that template parts would be similar to just adding a container to the page, but the patterns that exist inside them would be defined by a Block Pattern (ie. Header, Footer). This appears to change, slightly, how these mockups above work. We'll still be able to insert Header and Footer patterns from the Inserter, but they will be "Patterns" and not considered template parts. Template parts are merely the global container for the content. Related: #22034 |
|
My comment above was more about adding new patterns or variations within a template part. If the user were building a template and needed to add a template part from scratch, I imagine it would work similar to #21218 (comment). |
|
Howdy again. @enriquesanchez and I designed yet another iteration that tries to solve a few specific needs:
We did not add naming or renaming a template part to this prototype (yet) as I want to keep discussion focused. Again, this prototype makes a big assumption: 1. Only templates parts can be added to a template (at the top level). I don't know if this is absolutely necessary in terms of limitations, but it certainly simplifies things. For one, we can reuse the Inserter for template parts without adding a third column. The third column would likely add confusion as it would have Blocks, Patterns, and Template Parts side by side without a clear indicator of what each is ideally used for. For users that want to reuse something across posts inside their post content, they would need to use reusable blocks. Screenshots
Thank you to all the folks who jumped in jam sessions around this. |
|
I like this idea about how to create a new Template Part. I think it would make sense to add a 'category' or 'type' attribute to Template Parts as the current slug/theme alone does not seem to do them justice through these new ideas and iterations. But yes, creating a Template Part by selecting by type such as 'Header' 'Footer' 'Sidebar' 'Misc' etc. could set us up to use more semantic elements (header, footer, nav, etc.) for them and make searching/browsing through similar template parts much easier than the current slug/theme set up allows. Some other concerns:
I agree with this concern. However, I also feel that having the '+' button opening different inserters (either TPs OR blocks/patterns) in different circumstances just as concerning. It only makes sense given the assumption 'Only templates parts can be added to a template (at the top level).', which I don't believe makes sense for our circumstances. It also is not a solution for the page/post editors, and sounds like we would remove the ability for them to be used here? Why not "Only templates parts can be added to a template (at the top level)." ?A Templates ability to use blocks gives it the power to define structure. Structural blocks can be added to a template, and template parts (and post content) can be nested within that structure. Without blocks, wouldn't the Template just be a structurally agnostic list of Template Parts? If we wanted to define structure with that limitation, we would likely need to create structural Template Parts to nest other Template Parts in which would violate our second assumption 'Only blocks and patterns can be added inside a template part.'. The ability to use Blocks in a template seems like a good thing. Why not restrict Template Part usage in the post content?Im not sure whether or not this makes sense. Theoretically 'Template Parts' should be used as part of a 'Template'. But they are usable in other ways and may be able to provide other solutions other than how to divide up a template. I think one limitation with templates is that they are not able to divide up post content. This means we can not have a template structured to show: "Some post content", "A Template Part", and then "The remaining post content". But allowing Template Parts to be usable in page/post editors gives users the ability to do this. Although, it may be true that reusable blocks could handle all concerns here? Im not quite sure and it may be a bit early to determine? 🤔 |
Can you give me an example of structural blocks? Or an example of a use case where structural blocks make sense as wrappers for template parts instead of contained in template parts?
I suppose I'm not clear on any reason to add a template part inside of post or page content or in ways that aren't at the top level of a template. In you examples above, what is stopping them from using reusable blocks for those sections that need to be identical? They only have to edit the reusable block once and its change applies to the other pages, right? (If that's not right, we should fix that behavior) Also, if the reusable section is in the middle of a post, how would a template part be any different in workflow to a reusable block? |
Yeah thats correct, I didn't think that was the case at first. They seem like they would take care of any concerns there. Or at least I cant really think of any others? Im used to seeing them as insertable in those areas so I guess the thought of them not being used there takes a moment to get used to.
I guess whats nice about template parts is you can go to appearance -> template parts -> and open the editor for a specific template part alone. A similar system for reusable blocks could be useful, it could be an easier edit flow in some circumstances than trying to find it within post content. But that wouldn't be a reason to use template parts over reusable blocks in this way, just something we could consider adding for reusable blocks.
Well, going beyond the pure structural part for a moment: current Template examples I'm used to looking at (such as 'front-page' example) contain blocks and content outside of template parts or post content. This gives a clear division between 3 different types of content with different behaviors:
If we were to remove the ability to add blocks at the top level, that 3rd concern would need to be nested in a Template Part. Which then results in a Template Part that is not intended to be used in another template... which seems a bit odd. However, it does not seem like a standard use case (or does it?) to need this so maybe the option to do that with a Template Part in the end is an acceptable solution for that? Structurally, I was thinking columns/grids for nesting certain template parts in would make sense. But those seem like they would be for 'abnormal' template parts (not so much the standard header/footer), which we could probably be using 'reusable blocks' for anyways? If thats the case defining the structure in the template parts may not be bad. Conversely, if we want a template to show multiple post contents (like a page showing a handful of posts), maybe we would want to be able to nest those in structural blocks as having them in a template part would not make sense. Although, there may be other solutions to that as well. It's all so confusing. 😆 But I think we might be on to something here... |
Yeah, I think this is the big thing, IMO. You would probably implement a sidebar layout using a grid or columns block wrapping a template part/post content block right? I think beyond that, the difference between reusable blocks and template parts is still dubious for me. I know we've discussed this before 😅, but they just seem to accomplish very similar things for the user. I understand that template parts are currently related to themes (which is the main technical difference), but I could see it being very confusing for users to be exposed to two different mechanisms for having an area of blocks that is reusable. Technically, they both do very similar things, even if they have different roles (structure vs content). A couple of more specific thoughts about the design:
Very cool stuff, though, nice work! |
@noahtallen Probably not the grid block as it might behave unexpectedly with overflowing content. Columns might not be needed. I've got a feeling implementing a column grid for any block to use will resolve most of our layout issues. (will be posting mocks for that in the near future, but you can see a prototype here that takes a quick look at how they might work).
Good question. Really, there's no difference outside of potential use as a taxonomy and to make block/pattern recommendations. There's a discussion somewhere around here about adding semantic HTML elements to template parts. This could potentially be useful if we add the ability to replace (like transforms) template parts with another one. For example, you could replace one header template part with a different header template part.
That's great feedback. We're planning on finessing that a bit as we've received some feedback to help us improve the design of template parts in the inserter. |
|
Looks great.
Yes, because that's how they search for it again.
It looks good, but we need to think about where to place and how to differentiate customized template parts that have stuck around from a previous theme or template parts that were created from scratch by the user. Perhaps a subgrouping inside each category can work.
I think so.
I think it could work after we nail down the other parts of the flow. Would clicking "Browse all" insert the block to see the full list in the placeholder? |
What if the user is a theme dev? I feel like it may be confusing to have two names for the same thing, unless we also change our nomenclature for template part under the hood (which seems set in stone at this point.) 🤔 |
I think this could definitely cause confusion. If we only have 'blocks' and 'patterns' tabs, having it preview template parts to insert would seem misleading for the same reason having a separate 'template part' or 'section' tab on the inserter would be.
'Template Parts' is definitely an odd term for most users. The re-branding on the user end seems like a definite possibility, but I agree with Noah that it could cause some confusion. Due to this maybe we need a term that is a bit more semantic. 'Section' or 'Area' doesn't really carry much meaning past 'some group of blocks' or 'some division of the page'. Maybe something like "Reusable Areas" (being separate from but similar to reusable blocks)? Or something else to specify that they are intended for use across different pages (or templates!) 🤷♀️ |
@epiqueras Totally. I plan to seriously revisit this particular part of the flow. @shaunandrews has some ideas as well.
After getting some feedback, it's probably better to not show that button or the previews in the inserter. It likely will just add confusion and split the flow. It also raises questions like: What happens when someone searches for "Header" and there are header blocks, header patterns, and header Sections?
@noahtallen That's true. I think we need to default to naming that makes sense for the end users. "Section" may not be what we go with at the end of the day, but Template Part or Area might be a bit technical/scary sounding.
@Addison-Stavlo I agree. For now, let's not have anything but the Section block in the inserter.
I'm totally open to ideas. For now, let's stick with "Template Parts" in our PRs as I think we should tackle this in another issue. Thank you all for your feedback! |
|
I've done some rapid iteration based on feedback. Please take this prototype for a spin before continuing. The inserter
Change:
Section
Changes:
Changes:
Changes:
To doWe plan to iterate on this view:
There are parallels with other blocks. Perhaps what we go with could also be useful for inserting media if we decide to iterate on the current media modal. Perhaps not. Either way, the above view definitely needs iteration. Don't let that slow down this PR. |
|
@MichaelArestad for the "choose existing" I'd like to try opening an inserter focused on those patterns. Testing #22789 I'm finding the display of patterns there quite more promising than what i expected, and it circumvents issues with spacing and the somewhat confusing footprint of the in-page placeholder. |
@mtias I haven't been able to really figure this out nicely. I really wasn't feeling a 3 column version of the inserter. I could maybe try something like the inserter icon with a label as a full button that opens a Section-only inserter that is next to the "New Section" button. That would certainly simplify the design as it could use the same grid/patterns as the inserter. I'll mock it up shortly. |
|
Wondering if there's a way to polish the proposed interaction because it feels a little redundant:
I understand that what led us to this proposal is an attempt to avoid having Blocks, Patterns, and Template parts in the inserter. So I wonder if instead of working around that, we can find a solution to that particular issue. |
A second inserterI tried a prototype with an inserter opening when the user clicks the "Choose existing" button. Definitely try it out. Here's what that part of the flow could look like:
It doesn't feel too bad at all. I did try all sorts of button/inserter styles, but ultimately found them more likely to add confusion. Here are a few if you're curious. What do you think? Inserter with sub navI'm not particularly thrilled with this idea, but worth sharing. Here's a mini prototype.
I think it would likely add more confusion unless we did a different design treatment for the "Section" block. |
We can open the section picker by default when the block is inserted since it's the most natural flow, and users can always ignore it and click create new. |
That would be a good thing to test in a PR for sure. |
|
Are we planning on adding the name/edit/save toolbar at the top here? It does feel very familiar if you know about reusable blocks :)
|
I would prefer so for consistency. I do think it needs iteration, but that's a different conversation down the road. |
|
I like this! It doesn't feel like a '2nd inserter'... that is, it doesn't feel like a redundant confusing copy of the block inserter. It's more like having a popover to select the previews from as opposed to awkwardly expanding the length of the placeholder to smash the previews into like we are currently doing in the template part placeholder. On a separate note / an edge case of previews to start considering: After playing with different previews for these lately, one thing that feels awkward in general is previewing tall template parts. Consider a standard header may have a width:height ratio of 4:1 or more. Fitting a bunch of these in a preview looks great. Now consider we randomly have one that is the opposite, much longer in height by comparison. Maybe so long you can't view the entire preview without scrolling. They feel awkward when mixed in with the other previews. I wonder how we may want to handle this. Do we make that inserter as tall as full page-height if necessary? Do we only preview the 'top' section of a template part and cut-off the rest after a given height? Do we just preview the entire thing and deal with the awkward scrolling it adds in those rare circumstances? etc. .. just another thing to think about. 😄 |
|
We have to use a nice mosaic arrangement and play with the |
@Addison-Stavlo I agree. This is something I've been thinking about as well and is shared by block patterns. Perhaps in a future PR, we can design them to be a bit more pleasant. A mosaic view could work as one option. |
|
I tried a minor variation from the most recent where I remove the need to add the name of the Template part in the placeholder. Instead, it could be done in the Reusable block bar after the block is there like this:
Here's the link to this particular prototype. @epiqueras @Addison-Stavlo What do you think? |
|
Nice! That feels better. |
|
I'm torn, both variations feel good to me. In the original, the naming step seems more prominent and necessary. With the naming step on the top toolbar, it feels much more optional and unnecessary (from a naive user perspective) as the section itself starts to steal the focus of my attention at that point. The top toolbar would definitely be good for renaming or spinning a variation, but if we want users to take care in naming their new section I think the first flow fits more. However, the flow of clicking 'new section' and going right into it without being held up by that naming step does feel more smooth... I just wonder if we don't want to be too smooth in a case where we want to ensure care is taken with the naming step. In this new version, we would create the section with a default name "Untitled Section", "Untitled Section-2", "Untitled Section-3" (whatever is available if they had previously saved one as "Untitled Section") and they could then rename (or not rename) and save? Maybe its not a 'horrible' thing for new and/or neglectful users to end up with a handful of "Untitled Section"s since re-naming should be simple in this flow as well. Despite my semi-lengthy rambling, I'm good with whatever you guys think fits better. |
|
I wouldn't let them save anything until they set a name. |
@Addison-Stavlo @epiqueras It's my opinion that naming should be optional and unnecessary. It is handy to help a user remember what something is for or where it is used and that should be it. I don't think it should be used as part of a unique token/slug for inserting the template part.
That's something I think would be a really nice touch. Figma does this really well when I'm duplicating pages. If a page is named "cool heading i1" and I duplicate it, the new copy will be named "cool heading i2." |
It's not; it's only like that for non-customized theme provided parts. |
|
Resolved in #23295 |
We can currently (as of #21766) insert a "Template Part" via the Placeholder block:
Now that this flow is possible, here we can discuss future iterations on how to insert existing template parts.
Perhaps existing saved template parts should either:
related #21219
The text was updated successfully, but these errors were encountered: