Make usage of the settings icon more consistent and meaningful

[afercia]

Description

Splitting this out from #62129 where an interesting conversation about cohesive design language in the editor UI took place.

I believe cohesive language should apply also to icons and their usage in the editor.

Some icons represent very familiar logical concepts for users. For example, a plus icon + immediately associates with the concepts of 'Add', 'Create new', 'Insert', or 'Increase'.

Other icons need to be 'learned' in the context of the application and UI they are used into. This implies some initial cognitive load and learning curve. When users get familiar with the meaning and purpose of that icon, the icon helps identifying a specific feature in the user interface. As long as the usage of that icon is consistent.

Noting that, from an accessibility perspective, proliferation of icons is a problem and it would be preferable to have icons accompanied with visible text labels, but that's another issue.

Consider the following icon:

Its name is settings. Visually, it's two sliders made of a track and a handle (or 'knob'). Regardless of the icon name settings, I would say the logical association isn't immediate but can be learned. It's about values that can be 'adjusted' and 'set to' so that, in a broader sense, this icon represent the concept of 'settings'.

How this icon is actually used in the editor

At the time of writing this issue I can find 5 occurrences of icon={ settings } in the codebase.

In the first three cases, this icon isn't used to access 'settings'. Actually, it is used to switch a control to an alternative version where users can set custom values.

1
SpacingInputControl component.
By clicking the icon button the range control shows an additional input field where users can enter a custom value. There are many instances of this component for the various margin, padding, block spacing values etc.

2
FontSizePicker component.
Same: clicking the icon button switches the control from preset values to an alternative version where users can enter a custom value.

3
ShadowInputControl control in the ShadowPopover component.
Same: clicking the icon button switches the range slider to an input field where users can enter a custom value.

Important

So far, as a user I learned that this icon button purpose is to 'switch' a control to an alternative version.

As a user, it took me a while to 'learn' what this icon button is about. Now that I know what it is about, I would expect this icon to always be used consistently and always have the same purpose.

Instead, this is not the case.

4
The fourth occurrence of this icon usage is for the DataViews 'View options` button. Screenshot:

It opens a dropdown menu with a multitude of options for the data views layout, filtering, items to show, items per page. In this context, this icon button meaning and purpose are entirely different.

Important

As a user, I previously learned this icon means 'switch this control to an alternative version'. But now, suddenly, it means something else.

IMHO, this inconsistent usage doesn't help in building a cohesive design language. Also, as a user, the cognitive load is now doubled because I have to remember that this icon has different meanings in different contexts.

5
The fifth occurrence of this icon is in the Query loop block toolbar. Screenshot:

It gives access to a popover where users can set the items per page, the offset, and the max pages to show for the Query.

Again, the icon meaning and purpose in this context is entirely different and inconsistent. As a user, I have now to remember that this icon means something entirely different in three different contexts.

Conclusion

The 'settings' icon is a good example of how the actual icons usage can be problematic when it's inconsistent. Ideally, icons that need to be 'learned' should have only one, specific, consistent usage in an user interface. There is no point in forcing users to learn what an icon means when the icon meaning changes depending on the context.

Overall, I'd like to see a more strict, cohesive usage of icons throughout the editor, especially for icons that users have to 'learn'. I'm not sure the current situation helps much with building a good user experience.

To me, the cases 4) and 5) are less than ideal. Those controls should be changed to use another icon. The settings icon should be reserved to the 'switch' button for the controls alternative version.

The editor is already complicated. I'd think design should strive to simplify wherever possible and have UI conventions that are consistent to reduce cognitive load as much as possible.

Step-by-step reproduction instructions

N/A
Go through the various UIs illustrated in this issue description.
Observe the inconsistent icon usage.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[richtabor]

The fourth occurrence of this icon usage is for the DataViews 'View options` button. Screenshot:

Yes, this should be changed. Perhaps one of the layout grid icons, or the filter icon we're using elsewhere.

[richtabor]

The fifth occurrence of this icon is in the Query loop block toolbar. Screenshot:

These settings are better suited for the Inspector anyhow; I'd move them out of the toolbar completely. We have most query controls in the Inspector, apart from these; it's quite disorienting.

[afercia]

Specifically to the Query block, worth reminding the 'Display settings' button in the block toolbar is conditional.
When the Query block does 'Inherit query from template', there's no Display settings button, of course.
It only shows when the Query block does not inherit. See screenshots below.
In this case, I'm not sure I understand why the Items per page, Offset, and Max page(s) settings are separate from 'Order by' and other settings.

I'd agree all these controls should show up in the same place. Moving all of them to the Inspector could make the Inspetor too crowded though but I'd think it would be a good first step to make the Query block usage less disorienting.

Further improvements could be considered in a follow-up.

[afercia]

Re: the Query block settings, it appears there's an bug. All these NumberControl are wrapped within a BaseControl component, not sure why:

The help description of the 'Max page to show' is set to the wrapping BaseControl. As such, the description isn't correctly associated via aria-describedby to the NumberControl.

[mtias]

Indeed, this icon has spread too much for related but distinct uses. It was initially introduced for the extended color controls—it's a jump into more advanced, custom, or granular controls. For more general "settings" there is the cog icon to be used.

[afercia]

For the DataVIews, I'd lean towards the cog icon as well. Not sure we can use one of the layout grid icons, or the filter icon. The View Options menu contains heterogeneous settings that aren't just about layout or filter.

Looking at the material design icons for inspiration, something like the 'Dispkay settings' icon could work. In the meantime, I'd use the more generic concept of 'Settings' represented by the cog.

Comparison with some of the material design icons:

[afercia]

@ntsekouras should the 'Items per page', 'Offset', and 'Max pages to show' settings be compatible with allowedControls introduced in #43632? In that case, I'd create a new issue.

[ntsekouras]

@ntsekouras should the 'Items per page', 'Offset', and 'Max pages to show' settings be compatible with allowedControls introduced in #43632? In that case, I'd create a new issue.

I'd say not for now as they are quite basic important controls and a bit of different from the other controls (part of allowedControls). Having said that I don't have a strong opinion on this and eventually I think the direction is to use the new API to render the controls for each attribute, which is going to be more granular and available for all blocks.

Besides the above, I can open a PR to move the 'settings' controls in the inspector.

[afercia]

Thanks @ntsekouras I totally defer the allowedControls / new API thing to your experties.

I can open a PR to move the 'settings' controls in the inspector.

I already tried that in this PR: #63020 I'd appreciate a review, if you have a chance.