Exploration - Semantic template part contextual block patterns in inserter sidebar. #29595
Conversation
Immediate ConcernsThe interaction sort of raises more questions about design and whether or not these belong in the standard sidebar inserter. For insertion of these patterns to behave well, it seems like we would need to alter the behavior of inserting in this context. However, having insertion work one way in one context while having it behave entirely differently in another context would be an inconsistent user experience and potentially create confusion during interaction. Since these patterns are 'full' template part patterns, the current inserter behavior of appending beneath the currently selected block is problematic for a variety of reasons:
Problematic SolutionsOne might first think that a potential solution to this would be to change the inserting behavior specifically for these contextual patterns. For example, when the template part or any of its children are selected inserting a pattern would add it to the top level of the template part regardless of where the selection is (or similarly could 'replace' its contents instead of appending). While this would technically work for these patterns, its a huge difference in behavior from how the current patterns work. Adding onto this we would still want to show other pattern categories while in the template part context. There will be other patterns that may be found useful as sub sections inside template parts, these may include text patterns, button patterns, navigation or social link patterns, etc. These patterns would still need to have the 'normal' inserting behavior in terms of appending at the location based on the current selection. At that point we would have different categories with different inserting behaviors available in the same menu at the same time which seems like it would most definitely lead to quite a bit of confusion. |
Addison-Stavlo
changed the title
|
Size Change: +2.05 kB (0%) Total Size: 1.4 MB
ℹ️ View Unchanged
|
|
Thanks for putting this together! I totally agree that inserting the "full" pattern in to a nested layout block like a column makes for a poor experience. That said, I think it could be worth trying the following: When a Header pattern is inserted in to the Header template part, replace the current contents entirely but offer an "undo" affordance on the Snackbar confirmation. I acknowledge that this would be different to the standard pattern insertion experience. But I think that might be ok. The existing experience has been designed entirely around the composition of content rather than templates. I think the expectations shift with the context. What do y'all think? |
We can try that. My first thought is that the snackbar notifications disappear rather quickly though I think? I also wonder if we do a more persistent notification at the top (that actually requires user interaction to dismiss), if that would be better or too intrusive. Worth trying them out though. |
IMO offering block patterns |
Yeah thats a very fair point. Im wondering if we should just show template part patterns in the inserter under appropriate categories at all times regardless of selection, and have them behave as normal patterns there? Then the separate UI for patterns transforms could be where the real $$ is at for this contextual flow. 🤔 That said, Im not opposed to trying out Jay's idea with the replacement/notifications in this PR just to see what it would feel like. |
|
If we decide to rule out the replace idea altogether (I still think it's worth a try if it's not too much work) then I'm not sure that there's much value in surfacing patterns in this context. The appending behaviour is just too weird. I agree that the transform affordance would be adequate. |
At least not too much work for a prototype/hacky solution. Would definitely need some refinement on the code side though if thats the direction we want to end up going. So this PR will now replace ALL the contents of the template part if both:
Im not sure about the 'undo' button in the snackbar currently, but the standard 'undo' in the top bar works as expected.
If we do end up going that route, would we still surface the template part patterns in the normal context under their respective patterns categories (and just let them behave that standard way)? The idea being able to allow the flow of inserting that pattern at the template level, selecting the blocks, and triggering "create template part" from the ellipses menu? |
|
I spoke about this with some other designers today and consensus was that although the "replace" behaviour felt more natural, we should probably avoid it for now. There was agreement that the transform tool would be adequate (as mentioned in this discussion) and that the replacement behaviour would not work well for something like a Query block. In that case there's an argument to be made that you might want pattern insertion to behave as it does currently (IE if I'm editing a post inside a query) or as a replacement (IE I want to change the layout of posts in the query). |
That sounds pretty reasonable to me. I think any 'replacement' type flow seems like it would fit better in a specific patterns transform tool. Il close this out but we can always come back to exploring further in the future if necessary. |
Description
This PR explores showing semantic template part specific block patterns in the sidebar patterns inserter when when a template part or its children are selected.
To have contextual patterns to test with, we registered copies of the tt1-blocks theme's header and footer in
lib/block-patterns.Immediate Concerns
moved to comment #29595 (comment)
How has this been tested?
Screenshots
Types of changes
Checklist: