Behind the scenes of a punted feature of 7.1

Every release squad I’m on, there are different features that keep me up or wake me up at night. Sometimes it’s out of excitement. Sometimes it’s out of uncertainty. Sometimes it’s both. In this case of displaying inherited styles, it was definitely both.

Ultimately, this morning, the decision was made to punt the feature (link to the conversation in the release leads channel and a link to the GitHub thread). Here’s a re-share of part of what I said there: I’ll speak plainly and say that I am so frustrated we couldn’t get this in a better spot (not at anyone in particular, just at the reality of the situation). I really, really want our users to benefit from this landing. At the root of the reason why it didn’t land are a few things: lack of a solid design approach, lack of robust exposure and feedback from users due to it not landing soon enough, and lack of agreement on a way forward. What we did not lack is a willingness to try and experiment. Even if we have a strong idea that this would help users and are centering that, I would rather have more assurance it genuinely is helping in a way that makes sense. Similar to some extra Notes features, I hope to see this land in Gutenberg soon, perhaps first as an experiment to be extra safe. We can do a call for testing and get more direct feedback too.

With the above in mind, I wanted to preserve part of the journey of this feature partially to get any early feedback and partially to have a snapshot of the problems and solutions explored across a range of PRs.

About the feature

Since I ran the FSE Outreach Program back in the early days of the Site Editor, I heard feedback that folks couldn’t understand the hierarchy of styles. In some cases, I’d watch user testing where folks would style a template thinking it would automatically apply everywhere. In other cases, I’d watch people pick a style variation and then open block settings for an individual block in a template only to be confused not to find those styling options reflected in the sidebar. This longstanding problem has been something I’ve passionately wanted to see fixed for a long time.

At a high level, for this release, the full spectrum of the desired feature is to allow folks to see inherited styles reflected in the block settings, identify where they come from via breadcrumbs, override any inherited options, reset them back to inherited options when needed, and push any local overrides globally. This last aspect was actually split out into it’s own PR and approach here using a different approach separate from the overall feature for a simpler design, allowing it to land. The other aspects are what the rest of this post will focus on.

Evolution

Below is a look at an early version of what was developed with me talking through the default state and two options to show inherited styles: a blue dot and a diamond approach.

There are numerous issues with the above designs:

• The feeling of clutter/noise in the interface greatly increases.
• Debates over what’s better accessibility wise, a tooltip or infotip.
• Needing to make big exceptions to the overall design system per this comment.
• Severe layout constraints, considering the small space.
• The underline not clearly indicating a globally inherited value and not being very visible.
• Accessibility and design system concerns with the hover option also acting as a reset mechanism.

After beta 1, the problem then arose that a number of folks were on vacation this time of year or out for various reasons, hampering our ability to come together with enough perspectives. I noted this here as a risk. To keep working moving, I proposed two different possible ways forward:

Diamond with the ability to reset to inherited style

This option shows no indication of something inherited globally but it just reflects the styles you see in the canvas. If you override an inherited setting then a diamond appears to indicate an override (this should be a filled in diamond, sorry!). When you hover over it, you see an option to reset to the inherited styles. This reduces visual noise by not showing an inherited style while still allowing folks to see when they have an override and to reset to global.

Diamond with only a tooltip

This option also shows no indication of something inherited globally but it just reflects the styles you see in the canvas. If you override an inherited setting then a diamond appears to indicate an override. When you hover over it though, you ONLY see an indication that this local change is overriding global styles (copy is rough on this tooltip). To reset, you rely on the tools panel which we know is accessible and is a current known pathway. This is a more scoped down version of the former item in that it only shows a tooltip but without any ability to reset since that already exists in the tools panel.

This last option is what was then pursued in this AI generated PR from yours truly after being taken over by devs. This was possible to generate with AI thanks to the hard work to have a sound and robust technical approach by Aaron Robertshaw.

Exploring infotips rather than tooltips

During this PR, we went back and forth around tooltips vs infotips. Tooltips eventually won out but here’s a view of what the infotip component approach looked like:

Confusion around the reset method

Separately, within the comments of this PR, I noted a big drawback to losing the reset option baked into the same inheritance indication and shared the following video. Put simply, there are two different options to reset the values and it’s not clear why they are different:

This then led to, in some cases, a reset option being added separately to the controls as shown in this comment to help ease some of the confusion there for some of the options.

Adding back in breadcrumbs

Finally, after it felt like we were making headway with the above approach, I explored adding back in breadcrumbs to show where style options were inherited. This was built using AI and was made easy to do thanks to prior work by Aaron Robertshaw once more.

Lessons learned

Here’s what I learned in the process:

• Never lose sight of the overall user problem. Let that guide you to scope back solutions.
• Use AI once the foundation is built to explore many different options. Having clear visuals (even just videos) for folks to react to kept the conversation and ideas flowing.
• Land and debate pieces of work, while not losing sight of the spectrum of the feature set. This often helps find a way forward.
• Knowing a user problem deeply doesn’t replace user feedback on the solution at hand.
• Summer break in certain parts of the world at this time of the year is a real factor in planning for releases and needs to be considered.
• There are many considerations from performance to accessibility to design systems to navigate all at once. Seek those perspectives out and let them sharpen your approach.

Ultimately, I think this was the right call but it was extremely painful to make. On a personal level, I couldn’t shake not liking the diamonds in the interface nor how cluttered it looked so I’m excited to have more time to iterate, make it undeniably awesome, and land it hopefully for 7.2.