Align pattern / template part modal dimensions, and add view options

[jameskoster]

There are a couple of places where Patterns and/or Template Parts appear in modals, specifically the Pattern Explorer and the Template Part replacement flow.

Edit: Now also when creating pages, and working with empty Query blocks.

Pattern Explorer

Template Part replacement

As we apply this UX across different flows throughout the editor, there are a couple of issues we might consider addressing sooner rather than later.

Sizing

Patterns and Template Parts can often be large, so it's probably worthwhile mimicking the sizing from the Pattern Explorer in other instances. We may even want to revisit the full screen modal component concept in order to make the maximum use of space: #28574.

Consistent sizing will help make the overall UX feel more familiar and robust.

View options

Patterns come in all shapes and sizes so a strict layout for displaying them doesn't always work so well, even with a larger modal. As an example, the three column layout in the Pattern Explorer works well for the "Pages" pattern category, but less well for "Footers".

Pages	Footers

One option would be to employ a zoom scale so that folks can adjust the display based on the types of patterns they're browsing. Similar to apps like Apple Photos:

zoom.mp4

Todo:

• Make all pattern/template part modals the same dimensions
• Add display options to pattern/template part modals
• Make pattern/template part modals searchable Template Part replacement modal – make results searchable #40791

[richtabor]

I spun up a related issue here, but I'll close it and add my conclusions here (in addition to what @jameskoster is suggesting):

1. Remove single-view from __experimentalBlockPatternSetup

Take the block pattern selector (__experimentalBlockPatternSetup) and make it back to a grid view (not the current single pattern view). Consider even removing the single view entirely (not sure how helpful that is).

2. Possibly add another level of categorization for blockTypes

Consider adding a sub-categorization layer to blockTypes, which could be very similar to the current Pattern Explorer UI does (sidebar with search + category)). This would be particularly useful for the "Add new" pattern view, where I could select the type of page to add, instead of seeing an uncategorized list of page patterns.

This could also be interesting for the Query block's __experimentalBlockPatternSetup use case as well, where the query patterns could be categorized by column count, featured images, grid, etc. (If this is interesting, we should probably spin up another issue relative to this).

[jameskoster]

+1 on the additional categorisation. It will be necessary in order for initiatives like #41060 to be successful.

[jameskoster]

Prior to working on designs for a holistic pattern browsing component I figured it would make sense to list where we need to display patterns this way, and determine which features would be useful in each case.

Use case	Useful Features
Pattern Explorer Displays the full catalog of patterns	- Zoomable grid view - Sorting / Filtering - Search
Template part replacement Displays contextual patterns (IE template headers / footers)	- Search - Zoomable grid view - Carousel view
Creating a page Displays full-page layout patterns	- Sorting / Filtering - Search - Zoomable grid view
Creating a template Displays contextual template patterns (e.g a full 404 template)	- Search - Zoomable grid view - Carousel view
Inserting a Query Displays contextual patterns for displaying post lists	- Search - Zoomable grid view - Carousel view

Search and some kind of zoomable grid should be prioritised since every application will make use of these features. The carousel view is conditional but worth keeping as an option imo. Filtering / sorting is critical to non-contextual flows.

I plan to work on some designs this week, but keen to gather more input in the mean time.

[jameskoster]

Here's an example modal that makes use of all of the features we use across the pattern browsing experiences in Gutenberg:

pattern-modal.mp4

It should be possible to toggle the individual features depending on the use case as illustrated in the examples below, but the modal dimensions and feature behaviours remain consistent.

Template part replacement

Here filtering is omitted because context is provided by the template part being replaced. We default to carousel view, but it's still possible to switch to grid view.

Pattern explorer

Carousel view is disabled because generally there are too many patterns for it to be useful.

Creating a page

Here the side panel makes use of the drilldown component for nested filtering.

Creating a template / template part (header)

[Mamaduka]

I plan to work and apply suggested features to the Pattern Explorer modal first. Then, when I'm more familiar with the code base, I can give you a better answer if it's worth making an abstraction of this component.

[annezazu]

I wanted to bring in feedback from the nineteenth call for testing for the FSE Outreach Program:

I may have mentioned this previously in another testing, but being dropped on the “single view” when picking a different pattern makes it hard for me to even recognize that there are other options. The arrows are small and in the bottom left corner. I’d suggest starting on the “grid” view and giving people the option to click to see the single view.

As we think about aligning these various interfaces, I wanted to mention how the current experience feels. Something to consider, especially when thinking about wanting users to unlock the power of patterns rather than just thinking there's only one option potentially.

[richtabor]

I like the idea of one component that can be flexed to support the multiple pattern selection scenarios.

We should decide if we want to separate the presentation of full page vs. single patterns. Do we need a hierarchy category system for page patterns? Or should the new page modal just show the pattern's assigned categories (Text, Image, etc)?

Should there be a secondary page-specific category nomenclature for this modal?

Re the column control; it would be great if you could pass the desired column count for the modal.

[richtabor]

Should there be a secondary page-specific category nomenclature for this modal?

No need for secondary/sub categories, we can use the existing categories. Wrote an issue for this: #56944

[youknowriad]

Found this issue while triaging. I think there's an opportunity to use DataViews to power and unify all these UIs.

[jameskoster]

Yeah this issue was basically a pre-cursor to data views. Perhaps we should close it, review each such modal and create issues for those that could be migrated to data views?