-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Polish the swapping interface for template parts #31747
Comments
It might make sense to reuse the proposed modal design for pattern selection (#31033) here. I see three main benefits:
The thing I'm not sure about is where to place access to the switcher. One option would be to utilise the transform menu: replace.template.part.mp4It's not technically a transform, but I think the UX feels consistent and I like that it provides an option to include a "New template part" action. Another (less prominent) option would be to put it in the block toolbar ellipsis: Finally, we could just leave the "Replace" button in the toolbar, but it feels a bit prominent to me given that this will probably not be a common action for the majority of users. |
I think the modal design makes more sense for this flow and that the design noted in #31033 also seems like it would really work well for this case too. From the options you noted, I feel like the ellipsis menu might be the most fitting place to trigger this action. Although, I don't hate the idea of the transforms menu either. 🤔 I definitely agree that "replace" on the toolbar seems a bit too prominent for this. |
Digesting the conversation in WordPress/twentytwentytwo#123, I wonder how much we need to surface the technical differences between template parts and patterns. Another approach would be to allow folks to choose an existing header template part or a header pattern as part of a single "replace" flow: replace.tp.mp4 |
I really like this. It might be cool to list both templates and patterns in a continuous scrolling list (with headers for each section if we want them) rather than making folks click specifically into patterns from the sidebar. |
Yup, that's a good point. The technical distinction is probably bigger in my head than it is in any real-life user flows. Do you think there's any value in users knowing whether an existing header or pattern was bundled with their theme versus being pulled in from the pattern directory? Or whether those existing headers/patterns should just be prioritised in the list order? |
Yes, I do think some sort of distinction makes sense — whether that's a special section, a badge, etc. Whatever solution we come up with here might end up being relevant to #35364. |
It's fine and good to show both saved headers and patters (whether from the theme or the patterns directory) but it should be presented as two aspects since patterns are always a starting point and would require the user to possibly make some adjustments (to text, content, imagery, navigation), while their saved headers are presumably already set. |
Addressed in #38814 |
The current Template Part replacement UI looks like this:
The popover doesn't really provide adequate space to differentiate one template part from another. We might consider using a modal instead, similar to what is being considered for patterns (#31033) and the change template flow in the post editor (#31591 (comment)).
It may also be worth removing the replace interface altogether for general template parts. Their scope is so broad that it seems unlikely that one general template part will be ever related to other general template parts. And even if we are, the API doesn't provide any way to determine this.
The text was updated successfully, but these errors were encountered: