Section Styling: improving the UX of multiple levels of nested block style variations

[annezazu]

The Group block, and its variations, have often been created and used for controlling various aspects of a layout. As a result, it's not uncommon for patterns and layouts in general to contain multiple group blocks within them. When it comes to section styling for 6.6, this means that if you create a section style for group blocks, that option will appear for every group block, even if that group block is nested within another. This section style inception can be a bit confusing and leads to some unexpected results, depending on how the variation is built.

section.style.inception.mov

At other times, it can be a powerful way to style sections, including nested blocks as shown below, in a way that maintains branding and approach.

As this feature gets more exposure either way, I wanted to open this issue to capture related UX feedback as the current experience can be a bit tricky to understand, both for users and for block themers.

[aaronrobertshaw]

Thanks for creating this issue @annezazu 👍

The section styling feature delivered for 6.6 is definitely a first iteration and there is a lot more we can do to enhance the UX, UI, and power!

When it comes to section styling for 6.6, this means that if you create a section style for group blocks, that option will appear for every group block, even if that group block is nested within another

This is very much intended at this stage.

Perhaps the name "Section Styles" doesn't convey the full scope and level at which these styles can be applied. Sections of a page can be more than just top-level blocks/sections. There was also a period in some of the 6.6 highlight materials that section styles were referred to as one-click styles.

Consider a top-level section that contains a series of cards. Each card could also be considered a "section" and have styles applied to save tedious setup or enforce governance of brand styling etc. In addition, perhaps a given card should have a different set of predefined styles to the others, that could also be another set of section styles.

Early feedback reflected this ability to nest variations or section styles was very desirable. It's a big reason this feature didn't make 6.5 and faced several technical hurdles which are another story 😅

Here's an example that might illustrate some of the above nesting:

Screen.Recording.2024-06-27.at.9.38.09.AM.mp4

My view of the issue here is it is more related to the navigation of blocks and understanding what is currently selected. I know this UX has been earmarked for improvement for a long time but is growing more pressing.

we discussed an idea to perhaps have Block types support a pattern name or only work for absolute top level container blocks

I don't think we should be modifying the blockTypes property as currently its name communicates exactly what it does. During the implementation of the feature, a scope property was looked at but ultimately for the first iteration that was omitted.

The idea of the scope property was to help indicate whether a theme.json partial was a theme or block style variation but could also be extended to flag a style variation as suitable for templates, template parts, patterns etc. It's possible something like that could be used to achieve limiting block style variations to top-level blocks only.

[justintadlock]

Early feedback reflected this ability to nest variations or section styles was very desirable.

💯 to this. I'm already using nested "sections" in my theme, which is allowing me to accomplish things that were very tough to do in the past without custom CSS. Here's one example of using nested card sections within a larger section:

[annezazu]

Ah to be clear! This issue isn't against nested styling. I very clearly see the value of that and have heard a desire for that for a long time. It's about the trickiness of a UX that tries to provide styling options across top level and inner blocks, like you demoed above.

The idea of the scope property was to help indicate whether a theme.json partial was a theme or block style variation but could also be extended to flag a style variation as suitable for templates, template parts, patterns etc. It's possible something like that could be used to achieve limiting block style variations to top-level blocks only.

Oohh dig this 💡. Having some control over where the options appear seems advantageous as having them appear everywhere right now has some drawbacks, UX wise, depending on how the variation was created.

[annezazu]

Talked to @justintadlock about this a bit more and I'm going to update the title and description. I did a poor job of communicating this feedback and didn't mean to cause alarm or confusion. I jumped to a possible idea rather than letting the problem space sit. At the same time, I'm eternally grateful for you all talking this through.

[aaronrobertshaw]

Thanks for updating the issue description and title 🚀

This section style inception can be a bit confusing and leads to some unexpected results, depending on how the variation is built.

It would be great if we could add some examples or details around the "depending on how the variation is built" comment. I'm assuming this is related to inner block type and inner element styles being defined for a section without the view it could be reused for nested blocks.

FWIW the Assembler theme might provide some examples to follow. It's early days for the feature and themes adopting it so keep in mind there could be lots changing in that theme though.

The discussion here is greatly appreciated though. I think it will help inform the feature documentation that is in the works.

Having some control over where the options appear seems advantageous as having them appear everywhere right now has some drawbacks, UX wise, depending on how the variation was created.

Definitely! Unfortunately, the line had to be drawn somewhere in terms of what made sense as an MVP and the initial iteration that could be released with 6.6.

[richtabor]

I'm not following exactly what is confusing; if anything section styles could evolve to be more applicable to more blocks. I.e the "Dark" style could be applied to a button, mapping the same background/foreground color choices.

Maybe I'm missing something, but I'm not seeing anything unexpected in the screen recording. If you apply a "Dark" variation to contents, the style will apply to all its contents — whatever defined in the variation. If you apply a "Light variation to a group within it, then that will have the light styles applied to it.

[annezazu]

To me, the confusion is coming from two dual issues: showing inherited styles from the parent group styling (touches on this #43082) on the inner group block and communicating how these styling options function together. For example, I could see a user being confused how to accomplish what they want with the styling in terms of applying it at the right level. I tried my best to talk this through in the following video:

sectionstyles.mov

[bph]

UX issues came up also during recent Hallway Hangout. Here is a quote from the summary post:

One challenge immediately clear to attendees was that the interface becomes heavily overloaded for users. How do you avoid having all the section styles on every group block?

Currently, the block style variations that power the section styles are limited by the same constraints in theme.json. So they can only be assigned to a block type. Ideas discussed:

• Section / Block Style variations need more granular control to identify context. For instance, a header or an archive style would still show up in the editor for general group styles, or other container style blocks. They are not needed except in certain situations.
• There could be style variations that are hidden from the interface.
• Use of a filter similar to blockEditor.useSetting.before that allows you to conditionally display block supports based on context.