Depth of control for syncing with Global Defaults

[JohnPixle]

Description

Across our blocks, we offer excessive control over which styles will be synced to defaults. This causes un-wanted friction in UI and user's perception. In the context of a real workflow, things should be more simple.

3-minute video:
https://www.loom.com/share/3bdf12b939f74efd8a3cf2461a1e8e0d

For this issue I am using screenshots from the panels of the contact form block as an example.

The way we do it now is to offer “granular” control for the style syncing, and it causes 2 major issues:

• The UI becomes congested with the “sync” toggles and extra borders.
• Creates un-necessary cognitive load to the user, as it’s hard for him to keep track of which control is synced and which one is not. It’s like adding a new layer of complexity.

I don’t think that it makes much sense to have this deep level of control. Instead, we should look into integrating a more “holistic” approach.

We also need to thing about a safe fallback for existing users.

Suggestions

1. Sync per panel

We could have the “Sync with Globals” apply collectively on the Input styling panel in our example, instead of each of the controls.

And then follow the same approach for the other panels and blocks.

2. Sync per block

Alternatively we could apply the toggle to the block level, which is a more binary approach. Feeling a bit skeptical about this, I would go with the “per-panel” suggestion above, which is a middle ground.

Implementation

I am not sure how existing users might be affected by any changes on this, but If we reach a common conclusion, we can apply the changes only to the refactored contact form block for now, and then wait for the “Block UI re-organisation” cycle to roll out to the rest of the blocks.

Looking forward to your input!

@Codeinwp/otter-team

[HardeepAsrani]

I will share my thoughts about this later when I've done more research on FSE thing that we talked about but one thing I wanted to mention so I don't forget in future about Sync per panel option. Many times there might be 3-4 controls in a panel in which only 1 can be synced so it will be a bit confusing for the user on what exactly is being synced, they might think every value is being synced.

Apart from that, I agree that the current approach isn't the best one.

[mghenciu]

Good points John!

My biggest pain point with the Global Defaults, is the UI fragmentation it adds.
Essentially I think the issue is that we assumed this feature is/should be the default way of doing things, and that all the users should/will be using it. Which I am not sure is 100% true, anymore.

For this, I am suggesting 2 ideas

1. Convert the current UI to Core controls

If technically possible, I think in the next UI overhaul we can extend the Core way of dealing with Global Defaults, and add our settings. It will look something like this, and in the first frame (one from the left) all the colors are defined by the user, except the Button Text color (which comes from Global Defaults):

In this case, when the user opens the settings panel (3 dots top-right), they will have:

• the option to reset a value to Global Defaults
• see what values are Synced with Global Defaults and what is Custom
• acces a shortcut to the Global Defaults
• option to Reset all settings

Of course for this idea, I need to do more UI testing to see how it would work with other controls (padding, margin, etc), but we can look into it - if we have a green light, from a technical perspective.

---

2. Add a Reset to Default/Global Styles for Otter blocks

With this one, what I am trying to achieve is the the resetting to the Default State of a block, @JohnPixle you are probably familiar with this one from Figma, and it could be handy because it's component/block-wise.

So let's say I've added a Section Block, made some changes, but in the end I just want to revert everything to the Default State without losing the content. I would be able to achieve this by using the Reset to Default/Global Defaults:

When this function is used, a component will be reversed to its Default State, or to the Global Defaults - if it's a component part of the Global Defaults system.

---

While things will probably change a lot with the FSE, for example if you take a look at the screenshots from here, you'll see that we are going in a similar direction as Figma: Global Components, overrides, instances, inheritance, etc. So my second idea could be challenged in future.
But the whole point with the Blocks Global Defaults, I feel like it should be about defining the things in one place, later reusing them everywhere; we shouldn't go very far(now) with child -> parent overrides and so on.

---

When you get the time @HardeepAsrani & @JohnPixle, please let me know if this is doable from a technical point of view, and if this makes sense UX/UI wise.

[JohnPixle]

Excellent work here, thanks for the input Mihai. My suggestions are much more conservative on-purpose, while yours approach the problem from another UX perspective, which is great. 👍🏻

I think the issue is that we assumed this feature is/should be the default way of doing things, and that all the users should/will be using it. Which I am not sure is 100% true, anymore.

I agree, i believe the feature went "too deep" from the beginning, and this initial complexity may have discouraged users. With complexity, I refer not only to the fragmentation of the interface, but to the conceptual one as well.

On top of that, it's a bad timing to mess with terms like "Global", given the core work in FSE, where they try to approach similar problems. I believe we should align towards a simple and meaningful implementation and not over-extend.

From bitter personal experience I can tell that when a product tackles similar problems as the core framework (in our case core GB), in the long-run we end with conflicts of concepts, duplicated workflows and UX confusion. We need to avoid that in this case.

The top challenge as I see it, is that -due to the nature of the feature- we need to ensure that regardless the direction we take, we have a safe fallback for the existing users. I mean that if some users are using global defaults and we make a drastic change, we cannot afford for them to break their styles, because most probably they will break "globally".

I am sure that Hardeep will come up with some precious input regarding the technicals, and the implementation, but meanwhile let me add my thoughts to your 2 approaches.

1. Convert the current UI to Core controls

This does make sense UIX-wise, but I am not sure about the implementation, and how it will feel in practice.

1. I assume that if users want to change the color of the button text, they simply click on the “blank” color picker, and the value will override the global default value. Ideally, the overrides should be as simple as that.
2. I am having a hard time envisioning how this will apply to other controls (as you say). This will require us to make more use of the “toolbox” panel (the three dots), which is something we should see and evaluate how it will fit in the upcoming re-organised inspector tab.

2. Add a Reset to Default/Global Styles for Otter blocks

If we were to start from scratch and develop the Global defaults feature, I believe this should be the way to approach it. It is the simplest solution, and the one that makes more sense. Conceptually it makes use of a simple default / reset core mechanism, which is easy for users to digest.

A “reset style changes” would work as in your example, and the fallback should be to the global default value. If no global default value exists, the style should fall-back to the Otter default style definition of the block (core otter block styles). Such a hierarchy of styles is logical.

Based on it’s simplicity, I also find this approach quite future-proof to be honest, not sure why you are skeptical about this 😇.

Now, the challenge with this is that it needs a foundational re-work. as I see it. But it actually solves for the problems that Hardeep expressed above (and many others)

---

Let's follow up with this, I think it's worth the trouble. At this point I believe we should start from evaluating the technical possibilities, and see how we can build a simple and solid UIX around it, that does not interfere with core concepts.

Sorry for the long message and thanks for your time and input.

[HardeepAsrani]

With the new Sync Control UI that we added in Review Block, do you think anything else needs to be done to make things simpler?

[JohnPixle]

@HardeepAsrani I think the UI we did for the review block simplifies things a lot. I would suggest that we roll it out gradually to other blocks, and follow a wait & see approach. Cheers! 👍🏻