Patterns: add opt out preference to the 'Choose a Pattern' modal when adding a page #65026
Conversation
|
Size Change: -514 B (-0.03%) Total Size: 1.78 MB
ℹ️ View Unchanged
|
|
Nice, this looks great. If I tick the checkbox in the settings, I'd expect to not see the modal until the next time I create a new page. |
That makes sense. We could do away with the preference and modal changes altogether. In fact, without looking too hard, it'd just be removing the useEffect here: gutenberg/packages/editor/src/components/start-page-options/index.js Lines 180 to 183 in 57183de |
|
Flaky tests detected in 8799cd3. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10731517185
|
So, that just ensures it doesn't appear again in while the post is open. Kapture.2024-09-04.at.15.29.01.mp4Better, but it still opens when you return to the same page and the conditions are met. So in that case a preference would probably be in order given the premise of the issue:
Still, I've removed the |
andrewserong
added
the
[Feature] Site Editor
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
andrewserong
added
[Feature] Patterns
|
I like this idea! Just pinging for design feedback 🙂 |
|
Thanks for working on this. I'm not too sure about this particular implementation, though; through its label and placement, that checkbox gets HUGE prominence, enough that it seems to suggest: you should check me. Almost like onboarding tutorials which should be easy to not show again. This is not that. Although there are genuine frustrations expressed—and we should provide an opt out—this is something that's genuinely meant to provide a better page authoring experience, and we're actively working to improve that flow through adjacent features (zoom out, select mode, contentOnly editing). It's too early to give the opt out this much prominence. That's why I suggested it live in the preferences section. It's fine for it to live only there, at least until we've gotten further with the flow improvements and validated whether they address the frustration or not. |
Okay, thanks for the quick feedback here. 🙇🏻 At a very minimum, I think the modal should not continuously show when flipping between the page and its templates. It's pretty spammy right now and I can empathize with user frustrations. We can achieve that by removing the I can roll back the changes to the modal footer and if folks are fine with it, leave the preference toggle in. Whatever flow improvements occur later, we could still activate the modal under different conditions: zoom out, select mode, contentOnly.... |
I agree—thanks for the insight. If the opt-out is too prominent, many users may disable it out of habit. Since this element seems crucial for the future experience, I'd also suggest offering the opt-out as a setting checkbox only. |
|
Yep, there really are many things we can explore later on, including if need be that checkbox in a place that manages its prominence. As noted, depending on where zoom out features land, this interface remains in flux. That's also to say, my feedback is specifically on the checkbox in the modal (for the time being!). Anything else, please refine and improve the user experience beyond that as much as you can 👌 🙏 |
|
Personally I still don't like this approach. The modal pops up without the users prompting and completely blocks what they expect to see. Making it dismissable is like saying "don't annoy me again", when we could have not-annoyed them in the first place. I proposed an alternative in #56181 (comment) |
Thanks again for the feedback, everyone. I think the negative UX definitely warrants an alternative approach, but taking @jasmussen's feedback above, it sounds like folks are actively working on it. To inch things forward and mitigate the present state of things, I'll pare back this PR to keep the preference and ensure the modal doesn't show its face as you navigate between the page and its template. Any redesign or refactoring can be in a follow up. |
…l when adding new pages. Adds a footer to the modal component.
…o that the preferences modal has a value to test.
…vents the modal popping open between page > template part > page navigation.
Removed modal footer and related components
ramonjd
force-pushed
the
try/add-pattern-selector-preference
branch
from
798d63b to
01552df
Compare
| @@ -152,6 +154,18 @@ export default function EditorPreferencesModal( { extraSections = {} } ) { | |||
| 'Enable pre-publish checks' | |||
| ) } | |||
| /> | |||
| { starterPatterns?.length && ( | |||
| <PreferenceToggleControl | |||
There was a problem hiding this comment.
I added this under "Publishing" for no real reason. Is there a better category?
There was a problem hiding this comment.
I'd possibly lean ever so slightly toward Interface as it's about what we're showing to the user in the UI rather than publishing per se... but I don't feel strongly about it!
There was a problem hiding this comment.
This is generally testing really well for me. Just left a note about an edge case with the rendering of the preference. But the removal of the useEffect in particular is really nice as it means we can toggle between template part editing and page editing an empty page without getting the modal showing again.
2024-09-06.15.55.51.mp4
Something I did notice (and not sure if this is really an issue in practice) is that if I'm editing an empty page within the site editor and then go to toggle the setting to show starter patterns back on, then when I close the preferences panel, it immediately displays the modal. Arguably this might be a good thing if someone is deliberately trying to get that modal back again:
2024-09-06.15.56.44.mp4
Separately, I also noticed that sometimes the modal opens twice very quickly when creating a new page. I think this might be related to the issue raised about the editor welcome modals, but just thought I'd mention it in case you're able to reproduce it. It's in the first video in this comment — if you scrub through very slowly, you can see the modal opens and then re-opens like something has triggered it to re-render somehow? In any case, I might be overthinking this part of it 🙂
Overall this feels very close to me, though!
| @@ -152,6 +154,18 @@ export default function EditorPreferencesModal( { extraSections = {} } ) { | |||
| 'Enable pre-publish checks' | |||
| ) } | |||
| /> | |||
| { starterPatterns?.length && ( | |||
| <PreferenceToggleControl | |||
There was a problem hiding this comment.
I'd possibly lean ever so slightly toward Interface as it's about what we're showing to the user in the UI rather than publishing per se... but I don't feel strongly about it!
I noticed that too and came to the same conclusion. There's a bit of a modal boxing match going on, especially when you throw the welcome guide in 😄 I can't shake the feeling I'm tinkering with superficial changes to mask a fundamental UX failing here. We want to expose useful patterns to the user when they first create a page, assuming they're going to add content to the page. If they don't add content to a page, the editor relentlessly throws up the modal, and over the welcome guide too. We've defined "useful" patterns as those that have a root block type of 'core/post-content'. We don't know the user's intention. They might want to create a contact page. Is the editor really helping by displaying the same patterns every time they create a new page? Presumably users are smart enough to learn that a wider variety of patterns are available via the pattern inserter. I know design folks are working on this problem, but I'm not convinced that keeping the modal around until things are better is valid. I hope this PR makes things a little better if it lands! |
Also, move pref to the right location :)
|
Thanks to everyone who has provided advice and helped test! I'll leave it to stew and merge early next week, when I'll try to think about some sensible follow up suggestions. 😄 🍺 |
|
Just did a quick test of this! Super appreciate having this as a preference. I wonder how it might work if this ever proceeds: #61489 but that's neither here nor there for now (and it would be easy to remove this). Referencing the discussion above, I agree on not having a tick box in the modal. It's far too prominent. I found that turning back on the preference when I do have content on a draft doesn't initiate the modal and, if I have no other content, it does initiate the modal. That feels expected! |
Nice work here, looks good to land now. I think it does indeed make this better for now! 🎉 |
|
Hey @ramonjd 👋 Would you be able to help write a dev note for this for the 6.7 release? We are planning to have this as part of a larger Miscellaneous Editor Updates note. We are hoping to get all drafts in by October 13th to leave some time for reviews before the RC1. All Dev Notes get tracked in #65784 so feel free to leave a note there or ping me directly :) Please let us know if you can assist with that. Thanks in advance :) |
Dev Note: new preference to disable the "Choose a pattern" modal when adding pagesA pattern selector modal appears when creating pages. The modal will reappear so long as the the page content is empty. In 6.7, this feature can be toggled on and off through a new "Show starter patterns" toggle switch, located in the "Interface" section of editor preferences. |
What and how?
Fixes: #56181
Deleting the entire modal is too easy, so this PR:
Previous attempt here:
Why?
When creating a new page, the "Choose a pattern" will not go away until you choose a pattern. I grow weary of it.
Testing Instructions
Tip
If you see the welcome modal competing for your attention, please ignore. I added an issue: #65104
Testing Instructions for Keyboard
Screenshots or screencast
Kapture.2024-09-04.at.14.16.42.mp4