Move the Block Patterns UI to the inserter #20951
Conversation
youknowriad
added
[Type] Enhancement
| @@ -3,7 +3,6 @@ | |||
| */ | |||
| import { | |||
| map, | |||
| pick, | |||
There was a problem hiding this comment.
The code removed in this file is moved up to be shared with the patterns.
|
I don't think we should do this until we have a finalized design for the inserter as a whole. |
| @@ -99,6 +117,17 @@ $block-inserter-search-height: 38px; | |||
| } | |||
| } | |||
|
|
|||
| // This extra div is needed because | |||
| // flex grow and overflow auto doesn't work well together. | |||
| .block-editor-inserter__scrollable { | |||
There was a problem hiding this comment.
I spent hours trying to make scrolling behave properly without this extra div without any luck. There's a mix between flex, auto-height popover computation, and scrolling that makes it hard to achieve. This solution is decent I think.
|
Size Change: +1.01 kB (0%) Total Size: 841 kB
ℹ️ View Unchanged
|
We had envisioned that the top search field will act as a global search, for both blocks and block patterns. Something like this:
Would that be technically feasible?
Should disabled patterns not show up at all instead? I wonder about how to communicate why a pattern is disabled.
Do you mean containsers such as the group block? Are there any others you had in mind? |
Yes, it's possible, the idea is to build things in steps as this is mentioned as a follow-up.
When I say "disable", it doesn't necessarily mean a disabled button, it can be hidden.
Group, columns, cover, media & text and any third-party container block. @mtias @enriquesanchez Let me know when you have a good design you want me to use as a target. |
I've been thinking a bit about how this could be handled, particularly for template building / theme editor. Perhaps we need a |
|
About this branch: this feels very promising, because I believe it's important that there remains only a single unified button to insert content. However I agree with Matías, it would be good to have a design ready before we go here. One observation: clicking the Patterns tab takes a few milliseconds longer, presumably because it loads the block preview component that renders each block. This is with only 3 patterns present. It seems worth to: a) try this with a bunch more patterns to see how much worse it gets, even if it's just duplicates of the same patterns
The placeholder component is a powerful pattern for surfacing complex features in a simple-to-use way. In that vein, it seems like it could be a good way to surface patterns, which might otherwise "feel complex" when in fact it's supposed to be the opposite. If a section of the page shows thumbnails for you to pick from, it can be as little as one click to get something nice going. But it does raise a few questions:
A placeholder for patterns really seems to make the most sense when inserted at the root level. In that vein, perhaps to truly enable page building with patterns, this suggests a rethink of the "trailing appender". This one:
What if this interface defaulted and heavily leaned into suggesting patterns as the next section of the page. What would that look like? Would it default to inserting pattern placeholders, or would it simply show an interface to browse the patterns there? |
This is an issue regardless of the UI, we definitely need to find ways to improve this (even in the sidebar). I believe @retrofox @marekhrabe @obenland and friends already faced and explored solutions for this? |
Inserting patterns inside blocks definitely make sense for me. Groups, columns, even post-content blocks |
To me those aren't patterns. Those are blocks. I'm eternally open to be disagreed with and overruled here, but to me a pattern is multiple blocks that are customized and visually styled. Columns is an ingredient in that, not a pattern itself. |
|
@jasmussen Looking at the current patterns, I don't see why I won't be able to insert the "two columns of text" pattern inside a group block and apply some tweaks (background color, full wide,...) to the container |
I don't disagree. I'm personally fine if we think patterns can be inserted at any nesting level. In the case of limiting the nesting level, I was primarily referring the theoretical "pattern block" that Matías suggested. |
|
Here's a couple of my thoughts on this as well... I also view patterns as a section of blocks. For me, this means a couple of things.
I'm open to any disagreements here. 😄 These notes are just my paradigm of patterns. Do we need to define what patterns are further? Maybe something like, a Pattern must include 2 or more blocks. |
Yeah, definitely something to improve. I haven't taken a look yet to this PR, but pretty sure it happens in other places where the |
We faced it with the page layout selector on wp.com and worked around it by using static images instead. We traced it down to |
|
For the display of pattern previews we should apply a windowing technique. |
youknowriad
force-pushed
the
update/patterns-ui
branch
from
f6b8156
to
f267d2e
Compare
|
Based on the last designs on #21080 It seems like this PR is moving toward the right direction. For the sake of iteration, I'd like to propose that we move forward with the current state and continue the inserter iterations on small PRs to achieve the designs there. I believe the proposal is good enough and better than master (which mean mergeable state). Unless you think we should do it all in one PR? |
|
@jasmussen I was not able to find a good fix for the "cropped thing", in fact I don't understand the issue yet :P can you help? The patterns tab stop, yes, it's the iframe. I though @aduth fixed a related issue on the third-party library used there but maybe it's not updated yet? |
|
Actually before you merge, I'm seeing one regression. The normal block toolbar is-pressed state appears affected negatively by changes made in this PR:
It's probably just a background color applied on hover, or something like that. Here's how it should look:
|
|
Going to revert the change about the auto-closing breakpoint. Our tests break spectacularly because of that, it seems there's no easy way to change the browser window size in Puppeteer at the moment so we're always considered in a big screen. you can also have this right now which is not great
|
This reverts commit ea6a344.
|
One thing to double-check is that it's not possible to render empty patterns menu by unregistering all patterns (#20867). |
|
Wow, this is really great! 🎉 Short feedback:
|
|
Would it make sense to call "block patterns" just patterns? The fact they consist of blocks shouldn't matter much to user?
|
|
@simison that's already the case :) and I confirm that I added the logic to remove the tab when you unregister everything. @Soean good feedback, the patterns title removal was a design choice (discussed a bit above) |
|
On teams of writers, having the pattern title visible is helpful. One team member asks, "Which pattern is that you used in X post?" Another team member can tell them the actual title of the pattern, which can be seen in text and hopefully searchable. Just a scenario I've already seen come up. |
Totally valid, and easy to pull back. We can revisit this. |
Refs #17335
This PR is the second iteration on the block patterns UI. It moves the block patterns into the inserter.
It is only enabled for root-level insertions.
Potential follow-up tasks: