Template Part Placeholder - Try more descriptive and contextual button labels. #33783
Conversation
Addison-Stavlo
added
[Feature] Full Site Editing
[Block] Template Part
Addison-Stavlo
requested review from
vindl,
jeyip,
mattwiebe,
david-szabo97,
Copons and
creativecoder
|
Size Change: +531 B (0%) Total Size: 1.08 MB
ℹ️ View Unchanged
|
|
For future reference, here's what the older selection looked like.
|
|
Things are working as advertised in the site editor except for a hiccup in Firefox (unrelated to this PR) TestingRequirementsSite editor
Post editor (in progress)
Browsers
I'm seeing runtime errors when loading the site editor in Firefox. Something related to iframes. I see the same issue on
|
There was a problem hiding this comment.
The changes look reasonable to me. I also agree that the new button copy clarifies behavior, but I'm wondering about a few things.
- The subtext in the placeholder still reads "Choose an existing template part or create a new one", which has the older language. It might be worthwhile to update or remove the text.
- The button copy is quite long -- ideally it would be more concise. I'm not sure if it's possible to shorten the length in a meaningful way without losing clarity though 🤔
Good point. Updated!
I agree, it would be nice to shorten down. With the instructions updated we could go with "Connect to existing"/"Connect block" and "Create new (patterns available)". The buttons really seem to grab the eye before the placeholder instructions and if read first they really don't serve much detail... but the placeholder instructions are there and they do look better this way: 🤔
or similarly: |
Yeah -- I totally agree with buttons catching the eye first. Seeing both options, I prefer the longer button text for clarity. Placeholder subtext would be redundant in that case, but we could probably update it to be more relevant. Either way, good call on the design feedback flag. 👍 +1 from me when we decide on copy |
|
I'm a bit confused, what does "Connect block" do? Is it the same functionality as "Choose existing". To me those are very different contexts. I'm not convinced that "connect" is a clear indicator of what will actually happen upon completing that action. This button's action does not add any blocks to an existing header, right? Connecting infers adding to, which is not what we're trying to get across here. This button is an action to declare if you want to choose a template part that has already been created, or to create your own. I say "Choose existing" works here, but I do agree that changing "New template part" to "Create a new template part" would be better action-oriented text for the secondary CTA. Adding "patterns available" is out of context in my opinion. Another thing we can look at is adding a snippet about what template parts are in the placeholder description, instead of reiterating the actions (Choose existing and Create new template part). Here's what I'm thinking: |
|
I have to agree that 'connect' is a bit confusing for me as a term. +1 for what @richtabor added as it aligns with how I've been using this feature myself. |
|
👋 Thanks for taking a look @richtabor and @karmatosed !
I agree its not the best. My first thought was "Link" but that gets confused with anchor tag links, etc. It would be nice to have a shorter term to convey the longer more techy explanation "make this block reference an existing template part CPT".
Choose existing is actually the confusion point that prompted me to start this PR. In some user testing its been noted as unclear. If the user's goal is to choose an existing block pattern intended for a header, the "Choose existing" button brings them down the exact opposite fork in the UX flow. Where what they really wanted was the "Create new" flow, which gives them a step to select from patterns if they are registered. This is why I was hoping finding a better term to use for the "Choose existing" button and adding the conditional "(patterns available)" to the "Create new" button would aid in clarifying the corresponding actions. |
|
@Addison-Stavlo do you have any more insights from the usability testing? It might help to frame this as you seem to have some context we might not. |
I’m not following here. In today’s flow, clicking “choose existing” brings up the popover where you can then select an existing template part. And choosing “create new” starts you fresh with no existing template parts. Right? |
Yes, and not necessarily. In todays flow "Create new" leads to the block patterns setup component, the same component that is used for other blocks such as Query. When there are no block patterns matching the context, this patterns setup component automatically redirects to its own "start blank" step, creating the blank template part for you. That is what you are currently seeing, as no specific template part/header/footer patterns have been added to Gutenberg itself yet. However, themes and plugins still posses the ability to register the patterns that will enable this selection step. When these patterns are registered "Create new" brings the user into the patterns setup process, which lets them view available patterns and decide whether to choose a pattern or 'start blank' as the content to create their new template part with. (For more on testing this step, there are some instructions on the original PR to help register a couple test patterns #31155 ). This brings us to the conditional "(patterns available)" appended onto the button text. As given the presence or absence of contextually matching patterns, the "create new" button can have two seemingly different actions: automatically create a blank template part vs. give options of block patterns to kickstart a new template part with. Say a user starts their site with none of these patterns registered and uses "create new" to see the blank template part automatically created. Once patterns are added via Gutenberg, plugin, or theme updates if the user still sees the option as "create new" they are not going to have any indication that this button triggers a different action and more options than what they encountered before, so they probably wont be inclined to ever use it again. Adding the conditional "(patterns available)" allows the interface to convey the difference in actions and expectations and would give that user the necessary indication that using this button again would provide a different experience than what they had encountered previously.
Mostly just what I said in the comment above regarding some confusion on the buttons and their corresponding actions. If a user is aware that there are cool patterns for them to create template parts with (they could have seen something in the description or article about their theme, plugin, etc.), then they are sort of drawn to that "choose existing" button thinking they can look through those existing patterns to choose one. Other than that there aren't many other insights for this. One thing is that our popover for selecting existing template parts needs to be reworked/redesigned, although this may not be surprising since it was implemented in the very early prototyping stages of the project and never really had any design discussion in the first place. The previews are tiny which can make it difficult to get a sense of what you are selecting. There was also confusion of where previews started/ended and which titles corresponded to which items when they had a white background so we did a quick band-aid giving some subtle borders (#33733) to try to make that a little bit more clear until we can get around to rethinking the component altogether. |
Hi @karmatosed! Hope everything is well! 👋 Most of the comments from that usability testing sessions on this matter could be boiled down to the fact that folks don't easily see the difference between "patterns" (as in: content provided by themes/plugins) and "existing template parts" (as in: custom template parts created by users themselves), and for this reason they don't understand why they are prompted with existing content for both "choose existing" and "create new". To give an example of what might help clearing that confusion, my first idea was a 2+1 buttons system. Something like this:
This is also slightly exacerbated by the WP/Gutenberg vocabulary filled with very semantically similar words (patterns, reusable blocks, groups, templates, template parts, etc.), but let's not fry too many fishes at once. 😄 |
Description
Related to discussion in #29950. The template part placeholder's button names are not very descriptive for a new user to FSE. "Choose existing" for example could be easily confused with wanting to choose an existing block pattern for their template part.
Here, we look at changing the copy "Choose existing" to "Connect this block to an existing %s" (%s as 'header', 'footer', etc.). And update "Create %s" to "Create a new %s" with the added "(patterns available)" when applicable.
How has this been tested?
lib/block-patterns, give it a new name, and change its blockTypes to 'core/template-part/header'.).Screenshots
Types of changes
Checklist:
*.native.jsfiles for terms that need renaming or removal).