Visual Array Input UI: Tidy up, and ensure full support for dark and light mode

[Jamiewarb]

Referenced in #63

Overview

The visual array input could benefit from some improved UI, particularly to do with icons and dark mode.

Icons currently stay dark even in dark mode, so should become lighter versions.

The icon next to the group doesn't align very well, so that should be improved

[liamb13]

Proof of concept design quickly thrown together to help visualise some of my thoughts.

Rationale here; whenever I've used page builders in the past, initially it can get quite frustrating not knowing what category the block I'm looking for is classified under.

My thinking with grid view is to use the full real estate available to showcase a block screen shot instead. Focus that view on visual.

The list view then becomes available to the power users who know exactly where things are and what they want to do. Potentially block names (or a handful of them) could be displayed as comma separated string on the expanded=false view. But I think the focus on this view could be once blocks and their categories are second nature to the user.

Theres no doubt some exceptions and alternatives needed. My focus here is leaning more toward the outer blocks. Inner blocks shown as a screenshot may not make any sense.

Side note; Could be worth thinking a little holistically about icons and when they should/shouldn't appear. I reckon icons should only appear when the title or label fits on 1 line and doesn't have any other context clues.

So with the current layout, having icons next to category titles before a descriptor feels a bit jarring (and still would with finer tweaking of the spacing).

[Jamiewarb]

Great thinking Liam, and love the PoC designs!

I think I agree with what you're saying. The one sticking point for me, and a reason why I think we should still have groups on the Grid View (or at least a config option to keep them), is because we have quite distinct block groups planned.

Other users may not have this distinction, and so could likely remove groups entirely, or group them like you've done in the screenshot but turn groups off for a certain view. I like that flexibility.

The block groups I use and have planned to pre-include are:

• Core Patterns
• Blocks
• Reusable Bocks
• Niche Blocks

Core Patterns are the "system-defined" block patterns—i.e. those made by the designers and developers to give editorial users a headstart.

Blocks are the basic building blocks everything is made from.

Reusable are "editorial-defined" block patterns—i.e. those made by the editorial team within the CMS. This could be whole page layouts for quick landing pages, for instance.

Niche are basic building blocks made for a specific purpose—e.g. a "Job Listing" outer block that specifically connects to an application tracking system to display current jobs, like TeamTailor or Recruitee. They can be hidden at the end because they're never used anywhere else.

These groupings are quite distinct. Whether editors need to know about those groups is up for debate—it's just how I initially imagined it and have built it since. Perhaps an icon or a (?) tooltip could suffice. However I do like keeping Niche blocks away from the rest, and I think having a dedicated section for your Reusable blocks may be nice too.

With that said, there could be a world where Reusable Blocks are a different pop-up altogether, with different filters such as "Show my blocks", or show blocks tagged with a specific team, etc. Not 100% sure but I imagine that would be a future extension at this rate.

Lots of writing here, but I'm thinking an approach I'd want to go for initially is:

• Grid View and List View both show groupings by default, with config option to turn off groupings for one, other, or both
• Icons for groupings can be supported for those that want them, but lets remove them as the default as I agree with your reasoning
• I like showing the buttons for Grid and List side-by-side, that's nice
• I like the toggle for collapsing groups as well, very nice
• In the images the Tags are the same as the Groups—I would keep these as two separate taxonomies.

Last thing for me was, when hovering over an item in the List View, it would be excellent to display the image, so you can confirm it's the one you want. That should give the best of both worlds for power users.

The Prismic CMS has an implementation of this, where they list all blocks down the left side in one column, and clicking on one shows a preview on the right side. Similarly, WordPress shows a column of 3(?) blocks, and hovering over one of them shows a tooltip with the block preview. However we do it, I think that feedback is important