Feedback: Width options and icons are unclear

[carolinan]

During a user testing session on April 9, following the FSE outreach program testing call #4, users worked with the columns block in the site editor. Several users described that the options for wide and full with alignments are unclear.

• It is not obvious that an icon with a black background means that the specific option is enabled.
• It is not obvious that clicking an icon with a black background deselects the option and resets the block to a default width.
• It is not clear that the icon with the three lines of equal width represented a default width.
• It was difficult for users to switch between wide and full, and one user suggested that a toggle would have been easier.

Users that tried to enable the full width expressed that selecting the option made the block narrower than wide width,
because what happened was that they clicked on the wide option and deselected it, instead of clicking on the icon for the full width option.

Comments included:
I don’t see an option for full width? Ah it’s under alignment. “Alignment” sounds like left/center/right, not the size. What’s the difference between wide and full wide? I don’t see much difference in the preview.

Rather than Change alignment, I would expect Change Width. Also the icon is not really explicative (would expect arrows).

I noticed that even after changing to Full width, and clicking again on the Block Toolbar, says the Wide Width is selected.
User contributed screenshot and comment:
Screenshot: after setting the Full width, the Wide Width is showing as selected

The label is called change alignment, it’s not clear that you change the width here.

It’s not clear that the symbol/icon is Full width. It would make sense to have arrows to indicate that it should be full width.

User contributed screenshot and comment:
I cannot find the Columns full-width icon

User contributed screenshot and comment:
No option to select full width.

This option is under “Change Alignment” where I would expect “Left, Center, Right” not options about width

[annezazu]

Just noting that the feedback here should be addressed by working underway here: #28356

[carolinan]

A few more comments from the users:

Changing the alignment doesn’t give clear visual feedback if the browser window is small. There is no textual feedback, so it’s possible to see the change only if the browser windows size is changed.

The icon to change the width doesn't match the context, nor the label at all.

[annezazu]

Controlling width options came up once more in the fifth call for testing for the FSE Outreach Program and I wanted to pass along here for anyone as they consider improvements to width settings:

Content widths are very confusing. I’d expect default to be inherited from theme. For example, adding Columns block directly into “index” area content will render the block fullwidth. To control the width then, I need to wrap it in Group block, which is set to custom width while I’d prefer it to default to “Inherit default layout”. Why the content width is not working the same way as in block editor?

[carolinan]

Would it be possible to show the name (tooltip/label) "width" instead of "alignments", when only width options are available, and
"width and alignments" when both are available and so on?

[annezazu]

More feedback came in from @paaljoachim on this experience in the ninth call for testing for the FSE Outreach Program:

I am not able to see any visual difference between Wide width or Full width. Because my browser screen is not wide enough to see the difference. When I widen the browser window then I am able to see the difference. Should the Wide width alignment be response in relation to the browser size window? So the user will be able to see a visual difference in the backend when testing Wide or Full width.

This continues to be a point of confusion for users.

[carolinan]

Could we change the label and tooltip of this toolbar option to "Alignment and width" ?

[annezazu]

@WordPress/gutenberg-design ^ curious for more thoughts here and whether there are other PRs/issues to be aware of that relate to making width options a bit clearer.

[jameskoster]

It is not obvious that an icon with a black background means that the specific option is enabled.
It is not obvious that clicking an icon with a black background deselects the option and resets the block to a default width.

I agree with this, a checkmark is a more familiar pattern. Probably worth splitting this out into its own issue.

Also agree that text justification and container alignment shouldn't share the same tooltip label.

curious for more thoughts here and whether there are other PRs/issues to be aware of that relate to making width options a bit clearer.

I think this is probably tied up with the broader layout issues. E.g. #36082

[eric-michel]

@annezazu

Content widths are very confusing. I’d expect default to be inherited from theme. For example, adding Columns block directly into “index” area content will render the block fullwidth. To control the width then, I need to wrap it in Group block, which is set to custom width while I’d prefer it to default to “Inherit default layout”. Why the content width is not working the same way as in block editor?

This is something that needs some serious attention. I've agitated about this a lot and I imagine folks are probably getting tired of me commenting on it so frequently, so I'll link these two threads that contain a lot of ideas and feedback about this issue:

• Cannot apply wide or full widths to nested blocks with theme.json applied #33374
• Suggestion: Simplify the layout concept #36082

This issue is single-handedly preventing us from adopting theme.json for our main parent theme. It's a very unintuitive interface decision and would massively confuse our content managers. I think the concept needs a full rework, but simply swapping the default would be sufficient for our purposes.

[annezazu]

Hey @eric-michel - thanks so much! I'm very much aware of those other issues but I appreciate you linking to them and for your efforts to chime in in various places. Of the ones listed, if I were to mark one with the Blocking Adoption label, which would you pick? I'd like to make sure either clarity or a way forward is provided regardless of any solutions (I love to know if something is a "won't fix").

Separately, I wanted you to know that handling layouts in general is both a known pain point and something that's actively being iterated upon/explored. For example, here's a recent design exploration #42385 and a quick iteration on the labeling of some of these controls #41893. On a related note, have you seen the work around adding a descendent block styles mechanism? #41922 It might be of interest since it seems that the inner/nested block experience for things like Group or Cover is a specific concern (pulling from another comment of yours that I read):

For our users, the most common use-case for a group or cover block is setting that block as full width, applying a background color or background image, and filling it with content - most notably paragraph blocks. In the current version of Gutenberg, this causes paragraphs to be full width by default, which is a complete violation of a11y standards, not to mention perplexing for any user who is not super familiar with the editor. My users will expect any blocks they add to a full width group or cover block to behave exactly the same as blocks added to the top level of the editor.

Editing to add -- I see you've commented on a few other posts. I tried to find you in WPorg slack but just in case it's not the right person, I wanted to share these posts too that might help:

https://make.wordpress.org/core/2022/04/13/core-styles-and-theme-customization-the-next-steps/
https://make.wordpress.org/core/2022/06/24/block-editor-styles-initiatives-and-goals/

[eric-michel]

@annezazu thank you so much for the links! It can be easy for me to miss some posts that may address my concerns already so I will definitely dig into those soon.

If it were up to me, I'd probably mark #33374 as Blocking Adoption as it has the most conversation outlining the scope of the problem and how it's affecting theme developers.

However, #36082 is the issue that's tracked in #33447 - and has some more thorough ideas for reworking the overall concept - so I could see that potentially getting more attention. Ultimately I think both are productive.

I did see the #41893 PR, and actually got nervous when I did because I was worried that would be considered the "fix" for the problem and it would be left behind. For our purposes, changing the default to "Inherit Default Layout" (or whatever the label gets changed to) is the highest priority as that's what my users will expect.

[annezazu]

However, #36082 is the issue that's tracked in #33447 - and has some more thorough ideas for reworking the overall concept - so I could see that potentially getting more attention. Ultimately I think both are productive.

I agree with you here and am going to flag that as blocks adoption for now #36082. Thanks so much for sharing your insights so we can better have things labeled and addressed! Keep it coming.