Size Change: -416 B (-0.02%)

Total Size: 1.74 MB

_{compressed-size-action}

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: draganescu <andraganescu@git.wordpress.org>
Co-authored-by: scruffian <scruffian@git.wordpress.org>
Co-authored-by: richtabor <richtabor@git.wordpress.org>
Co-authored-by: jeryj <jeryj@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: annezazu <annezazu@git.wordpress.org>
Co-authored-by: ellatrix <ellatrix@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Still to do:

1. Add the media library button
2. The search shouldn't be sticky
3. The back button should be sticky
4. The scrollbar should be at the edge of the screen
5. Preview outlines need fixing

Tested this out and the biggest pain point I found is getting back to all categories as once you start scrolling the back button disappears, along with the title of the category:

Since it's a fairly small section to return to, it's cumbersome to have to scroll all the way back up to see more.

I'd be good to get this in as soon as possible, so it can be used in #61489. Even on its own this is a nice change for 6.6.

Are there any blockers?

Are there any blockers?

It's a pretty big change; I'd like more input from @WordPress/gutenberg-design especially.

I made the case for using the drilldown pattern when this was originally implemented, so it's a 👍 from me in general.

Another option could be something like to the block inserter, but with collapsible panels. Similar to Figma's asset browser.

But on balance I suspect the drilldown would work better.

In terms of UI there is a discrepancy between how the search box works and how it is displayed between tab panels.

Since we moved it inside each tab panel these two are to be solved:

1. should the search box always be the 1st item or should it be the second item after drill down header (back + title)? Should they differ between blocks, patterns and media to signify that for media it's not globally searching across categories?
2. what should be sticky on scroll? Both search and drill down header> Search too when a search is active?

The main motivation is to free up space for the canvas to be visible when you're building with patterns, especially in context where the inserter stays open as you build. That's valid enough, and if those pieces come together, this drilldown mechanism can work for it.

Here's trunk:

Here's this branch:

The issue Anne notes appears addressed. The main tradeoff here is that it's hard to quickly get a sense of all the patterns in the various categories. That's actually a biggish tradeoff, and it's not clear it's worth it to me. I do wonder, can we apply this drilldown pattern only to smaller viewport sizes?

If we do move forward, the media tab needs some love too:

Anecdotally, just today I went browsing to look for a nice pattern, and I had this branch checked out. I immediately switched to trunk because the clicking in and out was not a great way to browse.

Imo, if we do this, the pattern category selector should be be a select box at the top vs a drill down. That would solve the problem @jasmussen is describing I think. We need to think data views more here?

I'm not sure the dropdown would help. It's still two clicks and lacking the clear context of the category I'm already in. As noted, I don't know I'm suggesting this to be a blocker, it's ultimately a tradeoff, but at the moment I'm leaning towards finding ways to fit the inserter with the opened "tray" better on screen, than using the drilldown, or dropdown.

I'm not sure if it would be better from a usability perspective, but noting that the concept here would essentially be a data view grid with records grouped by category, which is a feature we want to add anyway (#57967).

@jameskoster The previews are probably a bit too small?

Potentially yes, it will likely depend on the pattern/category. The number of columns could be easy to adjusted, even by the user (which is also something we want to add to data views: #60630).

@jameskoster the previews in the data grid mockup you linked to are less than the two column previews from search results available in trunk which this PR also removes.

For what we assume is an seeking behaviour to complete a set (to assemble the page with good patterns) having many small previews in a constrained space is less useful than having few large previews because it's very easy and common and expected to just scroll.

I think the argument above is correct, but I do concede that having more than one in a view could be useful so it's not perfect. Yet, it's a good tradeoff considering the UX we aim for should resemble assembling a stack rather than finding waldo so each one larger is better than many of them smaller IMO.

@draganescu I think it's a bit more nuanced; we should be aiming to create UIs that can adapt contextually, rather than optimising only for one specific flow.

When you're initially building a page I agree the pattern browsing experience is better when the previews are arranged into a single column. But when you're searching for a specific pattern you've used before, a multi-column layout (or even a list) might be easier to scan. The benefit of using data views is that it empowers both the consumer and the user to craft a UI that best suits any given activity.

Anyway, I appreciate it's a rabbit hole, and way beyond the scope of this PR :D