Shuffle blocks for contentOnly patterns
#45618
Conversation
kevin940726
added
the
[Feature] Patterns
|
|
|
Size Change: +8.86 kB (+1%) Total Size: 1.3 MB
ℹ️ View Unchanged
|
|
Exciting! The Shuffle button is appearing, but I am seeing results that I would consider to be unexpected. For example I have a Group containing a single Paragraph block, and when I shuffle I'm presented with Header and Footer patterns. For the purpose of shuffle matches, I suppose we should consider things like Site Title, Site Logo, Site Tagline, Navigation, etc to be 'content'. Or perhaps there is a better way? |
Yep! That's a known side effect that could happen as discussed in #44581.
This handcrafted list could properly work for core blocks but not for third-party blocks. I'm not sure if there's a better way though, at least not without introducing a new API. 🤔 |
|
I can't speak to the technical side, but for this feature to work it seems very important that the 'content' blocks remain consistent as you shuffle. Would it involve a new API to allow blocks to specify whether they are 'content' blocks? |
|
There's already an API ( Upon shuffling, All the blocks and their attributes are changed except for the content attributes. That is, any attribute in the Paragraph block gets shuffled into what is defined in the pattern, except for the Is this the expected result you have in mind? |
Yeah how you described it sounds fine. So it seems we need to add |
Interesting. The technical problem is that those blocks don't have attributes that can be marked with the content role. The content for those blocks is stored as part of the site itself. This is at the very least a good discovery to make, even if it is a bit of a problem. |
|
Yeah hard problem here, here are some ideas:
This sounded weird to me, while there are some blocks that need to be ignored while comparing (mostly style related blocks like "groups", "cover"....), some container blocks shouldn't be ignored like "quote", "list" blocks and I believe the new versions of these blocks don't have a "content" role either.
This is also an interesting observation that may get us close to what should be the algorithm here :) So maybe the algorithm should be something like: 1- Take the list of blocks and remove from the tree all container blocks that are just about layout: groups, covers, columns, spacer (not sure if there are others) The problem I see in my algorithm is that if a pattern has "three" paragraphs, we would be able to shuffle it into a "four" paragraph pattern but we won't be able to get back to "three" anymore. So we could consider only matching exact number of filtered blocks. The problem is that we might end up with too few options. Also another problem is that if you can't transform from a query with "post-title" and "post-content" to a query with just "post-content". Makes me wonder if some blocks should be considered mandatory and others optional for example:
Anyway, this is just some rumbling to try to get us into the right direction. No perfect solution here it seems. |
|
The other thing that comes to my mind is that it seems that this is an AI ML problem. Maybe we can train a model manually using the pattern directory and apply it here. I'm not expert in ML but conceptually it seems like a good fit. cc @ellatrix |
Yeah, I think this is a problem 🤔 The more accurate the system is, the fewer matches that can be presented, and actually that might make it less useful and less serendipitous. It could be possible to loosen the rules and instead switch to a model where content loss is ok, but I think the UI would have to be different to a shuffle, and offer an easy way back to the original set of blocks (this might be a valid feature to provide anyway). |
I agree it would be a shame if there was only 2 patterns to shuffle between, but imo it's not a deal-breaker. I'd say that experience is significantly better when compared to shuffling between incompatible pattern configs. If we're worried about underwhelming, we might say "only allow shuffling when there are >x matches". It's also worth noting that it's a problem that will diminish over time after we connect to the pattern directory, and the directory itself grows. |
|
In b35142a, I inline two functions This commit roughly follows the algo @youknowriad shared in #45618 (comment). Instead of hardcoding the layout blocks, I use the This approach is obviously very precise though. Let's test it out and see if we can spot something we can improve. |
@kevin940726 Possibly |
|
That could work! That will also match something like |
|
It does feel like checking block supports is a better option, but at the same time I'd imagine the navigation block shouldn't be excluded (potentially its |
|
Gave this a test. It works very well with some patterns. I tried inserting a basic footer (Default footer from TT3), and it shuffled between a few different options: Kapture.2022-12-05.at.15.48.02.mp4As you can see, it doesn't consider the navigation block as content so it will use patterns that don't include it and may lose the selected menu. The other thing I noticed is that I inserted this pattern (Two columns of text and title): It doesn't come wrapped in a group block by default, so I wrapped it myself and added the content locking attribute. When I clicked shuffle, I guess the only available pattern was the one I inserted and it removed the wrapping group block. It feels like the |
It is preserved, but only at the top level. As soon as we modify the pattern manually (wrap it with a group block in this case), we can no longer reference it back to the original pattern (performed by a naive algorithm in |
|
Here's my take on this:
Ultimately, I agree we should not develop too many custom heuristics and that pattern matching is something we could employ AI training to assist with. |
|
@mtias Thanks for the feedback! Not sure if I understand it correctly, but there are some technical difficulties preventing us from implementing some of the details you mentioned.
Are we saying that maybe it's worth holding this for now until we research the AI possibilities? How do you imagine the implementation with AI would be? Do we implement the AI in the browser or in the users' WordPress instance? Or do we implement it in a WordPress.org API and call it from the client side? |
|
I opened an alternative PR in #47594 with a slightly different approach: instead of shuffling on inserted patterns, we only allow shuffling on the pattern blocks. This way, we can keep the information of the pattern and shuffle to different patterns with the same |
What?
A potential approach to #44581
Why?
See #44581
How?
This PR implements an approach to swap non-content blocks with something else in other patterns. Since that inserted patterns don't have any information about which patterns they're inserted from, we have to perform an algorithm to "guess" which candidate patterns are alike. The algo used in this PR is to:
__experimentalRole="content"in any of their attributes.Once we find a match, we then add the "Shuffle" button to the toolbar. If the user clicks the button, it will randomly choose a pattern from the list and apply all but the contents to the blocks.
To prevent choosing the same pattern that it's added from, we do an
areBlocksAlikecheck to see if the blocks look like existing patterns and filter it out.Testing Instructions
"templateLock":"contentOnly"to the top-most group of the inserted pattern.Screenshots or screencast
Kapture.2022-11-09.at.11.12.26.mp4