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: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: richtabor <richtabor@git.wordpress.org>
Co-authored-by: ndiego <ndiego@git.wordpress.org>

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

Not sure this is a great user experience. Without actual masonry layouts, which is an open question how well this can work for keyboard navigation, this is just going to create visual rivers in the text and cause things to not line up. It seems like if we want to allow changing the aspect ratio, it should change the aspect ratio of all previews.

This feature provides parity with the original Patterns page, which feedback suggests was an enjoyable preview experience compared with the cropping we see on trunk.

it should change the aspect ratio of all previews

That should be what happens. Aspect ratio is either:

• 1:1: handy if you want a perfect grid with everything lined up.
• auto: useful when you want the preview to more accurately reflect the pattern/template.

The latter comes at the expense of perfectly aligned text, which seems a reasonable trade-off to me. To perfectly align the text it would need to appear before the preview, which looks a little odd. Perhaps I'm missing an alternative approach?

It should work nicely with #63367, and I think we should probably concentrate on merging that one first so that we can better test this one.

Personally I'd echo Joen. This feels a bit weird and maybe too prominent? I'm also not sure about the feature parity argument, since the new list is now quite different with way more info.

Could this be something baked in the preview like a scrollbar or some interaction on hover (example zoom or something)?

Agree on the prominence. It could be an option we include in the view options menu instead:

I still think this is a situationally handy feature. The constrained square preview isn't a great way to browse templates, which are often quite 'tall'.

The main problem is these horizontal rivers:

When the text doesn't line up, it's hard to scan.

I agree, but I don't think scanning text is always the main concern in this layout. If a user wants to browse that way it would make more sense to switch to Table layout, or to toggle the aspect ratio to something strict like 1:1.

As a primarily visual layout, Grid should be optimised for scanning the Previews, and in some cases the 1:1 cropping makes that experience less ergonomic.

Another example is the media library, where you might want to see the orientation of a media item:

I appreciate your desire to improve this view, but without actual masonry, even scanning just the previews becomes hard, when the whitespace causes those rivers. Even if this is an optional view configuration, it does not seem useful in this state. How do other similar apps or interfaces handle this? How about horizontal masonry, where wide images push the next item in the row to the right?

I appreciate your desire to improve this view, but without actual masonry, even scanning just the previews becomes hard, when the whitespace causes those rivers.

Agreed. This is not ideal:

Not sure if it should be configurable by the user, but if we wanted a very minimal, non-1:1 previews, it could resemble many photos apps design: increased gutter spacing, no visible text.

It's actually not bad for patterns (and media library of course):

As seen in MacOS Photos:

That could be interesting to try (hiding the text, aligning each row along the x axis).

I think user configuration makes sense, particularly for media where cropping is situationally useful.

Now that view options live in a popover, here's an alternative design we might try; 'Preview display' with options 'Cropped' (square) and 'Uncropped':

When uncropped all fields would be locked as hidden except for the title which could appear on hover, just like the checkbox.

@jameskoster and @jorgefilipecosta can you confirm that this will be punted to 6.8? I'm assuming this is the case since it's not on the 6.7 project board, but this issue was listed in the 6.7 Roadmap, so I wanted to double-check. Thanks!

Yes let's punt this one, it's not high-prio until we get to the media library data view.

Closing this PR as it is outdated if we still want to have user-configurable aspect ratio we will need to open a new one taking into account the new view configuration UI.