Columns UI is still buggy and confusing

[mrwweb]

Describe the bug
Following up on #10560, the columns block is still incredibly hard to use and confusing. There are so many issues that I can't really isolate much beyond to provide some screenshots and a GIF of TABing around and trying to figure out where the columns are.

To Reproduce

1. Insert a columns block

Expected behavior

1. Columns should be aligned and not overlap
2. It should be clear where each column is
3. It should be easy to insert a new block into either column in any order
4. It should be easy to use columns with a keyboard or mouse

Screenshots

Desktop (please complete the following information):

• OS: Win 10
• Browser Firefox 63
• WordPress 5.0-beta1-43823, Twenty Nineteen, no plugins

Note: Updated the title which came off a little antagonistic. My apologies. That was not my best moment, and I'm being more thoughtful with subsequent bug report titles.

[pagelab]

Agreed. The lack of immediate visual cues makes quite difficult to understand how to fill the columns.

[StaggerLeee]

I suggest to fill each column with subtle background color. Something like #f5f5f5.
Give them (when empty) auto 100% width, and fixed min-height.

[pagelab]

Another option is to do just like Adobe Indesign and other desktop publishing apps: just add a blue border to show that this is a text frame.

[StaggerLeee]

With some paddings, please. Looks amateurish this way.

[mrleemon]

Figuring out where to click in Gutenberg is like playing hide and seek with the editing system. The columns block is a clear example.

[timnicholson]

I suggest to fill each column with subtle background color. Something like #f5f5f5.
Give them (when empty) auto 100% width, and fixed min-height.

The problem with that is that we can apply background colors and the blocks should reflect the proper color. If you mean just to start out with a light gray that could work although it then isn't WYSIWYG which is a main goal of Gutenberg.

BTW, the "clear" color button doesn't seem to work. I can't seem to remove a background color from a block once it's been applied.

Another option is to do just like Adobe Indesign and other desktop publishing apps: just add a blue
border to show that this is a text frame.

A blue border seems like a good idea.

With some paddings, please. Looks amateurish this way.

I'd actually like to suggest that we have some padding/margin options on blocks.

[slimmilkduds]

I have added a very subtle dashed border to the columns in the editor, it got great feedback from my users

[jasmussen]

I made a number of improvements in #11904. There are still many enhancements and refinements possible, but please test version 4.4 and see if it addresses any of the issues brought up here, and let's continue to think of ways to improve it.

[mrwweb]

@jasmussen Right now I've got beta5 running, but I don't see any notable changes. I thought these were in there, but is that not right? I don't want to give feedback before making sure I'm on the right version.

[jasmussen]

@mrwweb The changes at this time are mostly stabilizing the implementation that's there. In that vein you can see the fixes included in #11904 — mostly around the ability to select the contents of each column, as well as selecting the block itself, with the mouse. There are also improvements to the rendering on the front-end when you're using more than 2 columns, as well as the mobile view. I expect more radical changes to happen in the future, as the interface for nested blocks are improved further.

[mrwweb]

@jasmussen Sorry I couldn't get feedback in sooner. Life and work, y'know?

Anyway, there needs to be way more eyes on this than just mine. I am still incredibly confused by the bugs I'm seeing when first inserting a block. These screenshots are all with Win 10, Firefox 63, WP 5.0-beta5, no plugins, and Twenty Nineteen:

The way default flexbox children work, columns don't fill the initial block width:

Looking at the source is terrifying, so I can see how it might be hard to pull this off, but the current state is really confusing and hard to use.

The use of disappearing placeholder text (which is a research-backed bad way to identify input areas!) as the only sign of where the columns are makes it very confusing:

Even the neutral state (when cursor isn't in either column) doesn't scream "columns" to me:

And that neutral state doesn't come back if you add content and remove it:

Again, because of flexbox, short column content means the columns don't fill the width of the screen:

...and adding blocks can end up with really weird looking results:

Strangely, once an image is inserted, the boxes seem to stop flexing and become equal width. They don't contain an image that's been expanded:

Here's a GIF showing a lot of those initial states and how incredibly unclear the column boundaries are and how confusing the block inserter position is (the weird gray stuff during image insertion and toward the end is a glitch in the recording and not visible when actually using the editor):

Notably, at the end, I flip on the unified toolbar which means the column borders are now completely gone and what was very frustrating becomes nearly impossible.

The whole experience feels like it needs a rethink to me, but here are some immediate changes I would recommend:

• Columns should always fill the width of the parent block (as UI allows)
• Columns should always be equal width (at least until column resizing become available, and even then, I'd be very much in favor of only supporting a certain number of snappable resizing widths).
• The placeholder for columns should not be an empty paragraph but rather something that suggests both a boundary and emptiness. The image block provides useful guidance on this point.
• The inserter button should be centered in each column and persistently visible until a block is added to that column in a way so that the block is visible itself and can define the column.

This is so crude I considered not posting it, but here's the best I could get in a few minutes:

I hope this is useful. I'm excited to have a good implementation for columns in the editor some day, but if 5.0 launches next week, I'd prefer columns get dropped from the release.

[jasmussen]

Good thoughts there, thanks for the feedback.

I don't know why you're seeing these issues, many of them should be fixed in Beta 5, notably the arbitrary width issues, and the content overflow issue. It's possible that the version of TwentyNineteen that shipped with Beta 5 did not include some of the necessary fixes we've pushed. Those might not go out until RC1 of TwentyNineteen goes out. In any case, here are a few GIFs of what I'm seeing.

Vanilla editor styles:

TwentyNineteen:

Here's some Windows testing. Edge:

Firefox:

As noted, I agree there are many improvement that can be made. I like the suggestions on this thread, of showing some dashed outlines on the columns to make it more visually clear that you are editing columns.

Your suggestion of improved appenders also makes sense, in fact we have the "non-paragraph based appender" that might work well here:

An additional improvement, which @alexislloyd mocked up would be to include the columns count in the block toolbar itself:

[mrwweb]

@jasmussen I'm seeing the same arbitrary width issues with McCluhan enabled which makes me think it's not a theme issue (nor should it be, right?).

Yes to all the suggestions. Hopefully before 5.0 drops!

Win 10, Firefox 63.0.3, WP 5.0-beta5-43909, McCluhan 1.13

[mrwweb]

Update: Still seeing the "collapsed" initial display of columns with WordPress 5.0-RC1-43944 and Twenty Nineteen ("Version 1.0" whatever comes with the RC).

[jasmussen]

@kjellr Any idea why he might be seeing this?

[kjellr]

Update: Still seeing the "collapsed" initial display of columns with WordPress 5.0-RC1-43944 and Twenty Nineteen ("Version 1.0" whatever comes with the RC).

Interesting. I'm not seeing that when testing Twenty Nineteen with 4.9.8 + Gutenberg 4.5.1, but I am seeing it when testing the exact same theme version with RC1.

From an initial scan with the inspector, the markup looks the same between the two. Twenty Nineteen does not apply any editor styles to the columns block, but it's possible the theme is inheriting something weird. I'll keep digging...

[kjellr]

I'm seeing the same arbitrary width issues with McCluhan enabled which makes me think it's not a theme issue (nor should it be, right?).

Actually yes — I can confirm this. Using 5.0-RC1-43944, I'm seeing this with all themes. So I don't think this is Twenty Nineteen-specific.

Gutenberg Starter Theme:

Twenty Seventeen

[jasmussen]

Interesting. I can't reproduce but I'll give this another stab. I might ping you. Thanks Kjell.

[kjellr]

FWIW, setting the width of editor-inner-blocks to 100% appears to solve the issue. Though I'm not sure why that's necessary in RC1, but not in the previous Gutenberg version.

[mrwweb]

Can we get this into the 5.0.0 milestone please? :)

[youknowriad]

I think I reproduce with the RC but not with the plugin.

[jasmussen]

I will have a fix for this no later than tomorrow, so we can be sure to get that fix into the 5.0 release.

[mrwweb]

@mtias So the editor is really going to launch with columns like this? That is super disappointing! Columns are going to be one of those points of excitement and not fixing this sets people up for a big letdown.

[mrwweb]

@jasmussen @mtias @kjellr This is still the initial empty state of columns in RC3! Win 10, Firefox, no plugins, Twenty Nineteen.

Why was this punted to 5.0.1? This looks and feels like a bug that people will notice immediately.

[afercia]

The reason for the wrong width when clicking in a column is in the different order of the stylesheets in the markup. This is something that emerged also in other issues: either Gutenberg guarantees its stylesheets are in the expected order or some selectors should have a higher specificity.

Specifically, here's the current order in the plugin (latest master) and in 5.0:

plugin:
block-library/theme.css
block-library/style.css   > .wp-block-columns = display: flex;  = width based on content
block-library/editor.css  > .wp-block-columns = display: block; = width 100%

Result: display block prevails and the columns take all the available width.

5.0
block-library/theme.css
block-library/editor.css  > .wp-block-columns = display: block; = width 100%
block-library/style.css   > .wp-block-columns = display: flex;  = width based on content

Result: display flex prevails and the columns width is based on their content: when the placeholder gets removed, the column is narrower. To reproduce, you can also edit in the browser's inspector the placeholder text to make it shorter and you will see the column shrinks.

[mrwweb]

Thanks for the very clear explanation, @afercia. That makes a lot of sense. It also makes me wonder what else has broken for the same reason.

Here's an example of the content-driven widths you mentioned:

That almost certainly is not what a user will expect for a "two column layout".

[youknowriad]

AFAIK this is not an issue in the plugin, so I'm closing this issue in favor of this trac ticket https://core.trac.wordpress.org/ticket/45442

Let me know if I missed anything here.