Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Column width value changes. It's hard to set width. #16370

Open
phpbits opened this issue Jul 1, 2019 · 28 comments · May be fixed by #16822 or #19515
Open

Column width value changes. It's hard to set width. #16370

phpbits opened this issue Jul 1, 2019 · 28 comments · May be fixed by #16822 or #19515

Comments

@phpbits
Copy link

@phpbits phpbits commented Jul 1, 2019

Describe the bug
It's really hard to set columns block width. Other column's width are changing the values whenever other column width changes.

To reproduce
Screen Capture on 2019-07-01 at 21-19-46

@aduth

This comment has been minimized.

Copy link
Member

@aduth aduth commented Jul 1, 2019

From a technical implementation, this was tricky to find the appropriate "expected" behavior.

The current behavior is essentially:

  • When resizing any column except the last, the columns to the right of the one being resized have their widths redistributed to compensate (either expanded or reduced)
  • When resizing the last column, the above behavior is reversed (all columns to the left are redistributed)

So in your example, if you had resized the middle column instead of the last column, the first would not have been affected.

In retrospect (and evidenced by this issue), this behavior is not as obvious at it had hoped to have been.

I think it's fair to say we should optimize to try to reduce (or eliminate) the chance that if a user had previously assigned an explicit percentage width to a column, it should not be subject to future width redistribution. However, in pursuing this, we would likely encounter a problem the current logic is trying to account for, which is that without redistributing columns, we can't ensure that the sum total of the widths is 100. Perhaps this is reasonable, especially if we also consider to show some messaging to the user that the values they've selected are not "valid" (similar to the contrast warning?).

Thoughts? Suggestions?

@phpbits

This comment has been minimized.

Copy link
Author

@phpbits phpbits commented Jul 2, 2019

@aduth Yeah, that's tricky. What I did with CoBlocks resizing before was change the adjacent column width only and not distributed. In this case it's easier to manage the widths and still have a total sum of 100. I hope this helps.

@mapk

This comment has been minimized.

Copy link
Contributor

@mapk mapk commented Dec 24, 2019

I recently ran into this problem as well and would love to see one of the solutions offered above.

Is it okay if the values of the columns don't add up to 100%? I think so. Adding some text in case this happens seems is possible, but I don't think it should break anything if they don't add up to 100%.

For example, if I set each column to be 15%, it would just look like this on the front-end.

Screen Shot 2019-12-23 at 5 31 09 PM

Can this be a solution? If y'all think it's necessary for some messaging in the editor that the widths don't equal 100%, I can mock that up.

@aduth

This comment has been minimized.

Copy link
Member

@aduth aduth commented Jan 2, 2020

@mapk I'm coming around to this idea, since I think more often than not, the current behavior rarely results in an expected outcome, and is more frustrating than it is helpful.

That being said, there's a question from a usability perspective of whether there should be something to help a user create a set of columns which add to 100%. If we remove the current behavior, then it's up to a user to manually edit each column and assign their widths appropriately if they want to occupy the full width available. This was more of a problem before #16129, since at least now the most common arrangements are presented as predefined options.

I never explicitly referenced it here, but based on @phpbits advice in #16370 (comment), I had opened #16822 in the summer as a slight adjustment to the current behavior, in case that's something worth pursuing.

However, given the challenges outlined there, maybe the simplest option for moving forward would be to allow manual width adjustments to be truly manual. I do think if we go this route, that a warning would be appropriate to communicate to the user if the columns do not sum to 100%.

@mapk

This comment has been minimized.

Copy link
Contributor

@mapk mapk commented Jan 3, 2020

@aduth excellent! I think @talldan made a good comment in #16822.

It feels like this UI should be on the columns block, so that each column can be adjusted quickly, rather than clicking into the individual column. The issue with typing column width would also be solved if there were multiple range inputs and an 'apply' button.

I'll work through a couple ideas in mockups.

  1. Keep existing column size on the Column block, but show messaging somewhere to express total Columns block width for the user.
  2. Redesign the column widths to be on the Columns block so the user can see them all together and determine the overall width.
@aduth

This comment has been minimized.

Copy link
Member

@aduth aduth commented Jan 3, 2020

This ties in to #7694 and #15660 as well, where eliminating interactivity on the "Column" block necessitates that the existing controls be moved to the "Columns" parent. In fact, #16077 implements exactly this, though it maintains the existing behavior of resizing adjacent blocks. If we remove this behavior, I think it could simplify the pull request a fair bit. I think it could use some design thought as well, since I'm not sure if the range controls as presented are the best option.

Separately, #16024 implements the necessary work to disable interactivity on the "Column" block, but I think it can be addressed independently from the resizing controls.

@mapk

This comment has been minimized.

Copy link
Contributor

@mapk mapk commented Jan 3, 2020

There's a lot to consider here. Even #16791 and #16790 play into this a bit. Quite honestly, I think pulling the column widths out of the Column block and into the Columns block (parent) is a better way to go here. I created some mockups to convey how this might work.

Columns block - Initial state after selecting "3 columns" from the placeholder

Screen Shot 2020-01-03 at 12 18 38 PM

Columns block - manual adjustment of columns

Screen Shot 2020-01-03 at 12 18 57 PM

Prototype

https://www.figma.com/proto/gAjGzaH0nSiH7iFtSLPDTI/Quick-Mockups?node-id=152%3A113&viewport=947%2C339%2C1&scaling=min-zoom

Notes

  1. The Columns block inspector gets a proper accordion labeled "Columns Settings".
  2. Under this new accordion exists:
    • Number of columns.
    • Ability to toggle on/off the 100% auto width adjustment to columns.
    • Each column is represented as a range control similar to #16077.
  3. When a column is added or subtracted, a "column width" range control is also added or subtracted to reflect the change.
  4. Toggle "on"
    • When a manual number is set on one column, the next untouched columns adjust accordingly to automatically fill space and equal 100%.
    • When a manual number is set on two columns, the next untouched column adjusts accordingly to automatically fill space and equal 100%.
    • If last column accepts a manual input, than the previous adjacent column readjusts automatically to fill space and equal 100%.
  5. Toggle "off"
    • When first toggled "off" nothing changes in column width.
    • User can adjust each width as they see fit. These numbers can be less than 100%. (I'm not sure what to do if they all add up to more than 100%)
    • Warning message appears when the combined width does not equal 100%. (this needs copy review)
@aduth

This comment has been minimized.

Copy link
Member

@aduth aduth commented Jan 3, 2020

I like the idea of a toggle option to control whether the automatic width distribution should take effect. I still think, based on the early discussion in this issue, and the changes considered in #16822, we might still want to try to improve that default behavior. It also means we have to continue to deal with the complexities surrounding the width distribution, but this is more of a technical challenge that we can overcome.

I can see about reviving #16077 with some of these new iterations.

One thing which might impact your proposed design: If we go all-in for #7694 / #16024 so far as removing interactivity on the "Column" block altogether, we will need to find a place for all of the current column settings. Notably, this also includes the vertical alignment option for a column. My original thinking with #16077 in having "Column 1", "Column 2", etc. subheadings separate from the width control for that column was in order to better accommodate this possible need.

@mapk

This comment has been minimized.

Copy link
Contributor

@mapk mapk commented Jan 3, 2020

Notably, this also includes the vertical alignment option for a column. My original thinking with #16077 in having "Column 1", "Column 2", etc. subheadings separate from the width control for that column was in order to better accommodate this possible need.

Interesting thought. I imagined the "align top" settings for each column could remain part of the individual Column block like so...

Column block

But your idea to bring all the individual column settings into the parent Columns block might work well. This would move those settings from the block toolbar and into the sidebar. Does that feel okay?

@aduth

This comment has been minimized.

Copy link
Member

@aduth aduth commented Jan 3, 2020

I think it could go either way. The main idea with #7694 was to flatten the block hierarchy, where it is currently cumbersome to navigate in and out of the blocks in a Columns block. If it could be achieved, the only blocks that a user would select are either the Columns wrapper, or one of the content blocks within any of the columns (i.e. no "Column"; it technically still exists, but would not be selectable).

But, based on the discussion we're having here, it might turn out to not be worth the effort if we have lots of settings specific to individual columns such that it makes more sense that the user can and should interact with those individual column blocks (as it exists today).

@karmatosed

This comment has been minimized.

Copy link
Member

@karmatosed karmatosed commented Jan 6, 2020

Whilst I understand the issue attempting to be solved I do think that the solution is too complex and adds cognitive load For example, compare the old screen now to new:

1

2

I would argue you don't need to see all columns at once, can perhaps this distil down to just be the one you are in at that point? At any point, we end up with multiple elements doing the same thing we should consider how can we reduce and simplify.

I just don't think such a complex interface is a good step forward, but I do think we can have that functionality just not all on at once.

Looping in @jasmussen here as I know you have some solid experience with this type of distilling.

@jasmussen

This comment has been minimized.

Copy link
Contributor

@jasmussen jasmussen commented Jan 6, 2020

What a thread! And great ticket, thank you!

I'm just back from vacation so it's very possible my brain is still booting, but looking at the GIF in the original ticket, the solution seems very obvious to me: don't change any column values automatically. The fact that we do feels like a bug — I just typed in 20%, why is it now 30?

I understand why it's 30%. It's because we are trying to be helpful to redistribute the remaining space, as Andrew put it. But why do we? What if I want my columns block to be 200% wide? 4 columns each at 50%? Maybe I want that horizontal scrollbar — the Shelf theme does it.

Right now we are adding complexity in order to solve a problem caused by complexity in the first place. If we simply did not re-distribute column widths, we would not need any additional UI. Perhaps a small warning box that says "your columns block is now more than 100% wide" ([needs copy review]).

Are there other problems the redistribution of widths is solving that I'm glossing over?

@mapk

This comment has been minimized.

Copy link
Contributor

@mapk mapk commented Jan 6, 2020

While I understand the concern for adding complexity, providing a holistic view that is easily accessible is a plus. Right now having to click through individual columns to figure out their width is a process of "hunt and click". It's a bit daunting to try and remember where these settings are located. I've noticed this in usability tests as well. Seeing them in one place unifies the experience. It's extremely valuable to surface automatically adjusted parameters rather than making hidden automatic adjustments on unseen columns.

BUT that being said, eliminating the auto-adjustments altogether could be interesting. Maybe this is a good first step? Are there any potential theme-related problems that could arise from this?

Also, I agree we should communicate any non-100% widths to the user. Where should the warning text exist? As a user, I'd like to see a warning associated to the same area I created the error. So probably on the child Column block sidebar. But would it show only on that individual Column sidebar? Thinking this through, the warning indicates the overall Columns block width problem. IMO, that warning would need to show on all child Column block sidebars unless it gets resolved. Would we also want to show it on the parent Columns block sidebar as well? That last one seems too disconnected if I have to click to a child block to fix the width.

@aduth

This comment has been minimized.

Copy link
Member

@aduth aduth commented Jan 6, 2020

For example, compare the old screen now to new:

@karmatosed I don't personally feel that considering the two screenshots in isolation is a fair comparison because, for me, the bigger challenge in the current behavior stems from how a user selects these blocks (or even learns to know that they exist), similar to what @mapk is saying. Granted, it's a challenge that has and will continue to be acutely relevant as we transition into full-page editing, where many levels of nesting will be common (i.e. face the challenge head-on).

One thing that #16077 has going for it is at least that it makes the auto-adjustments more obvious in how changing one column will impact its siblings.

I agree that a good first step could at least be to explore a pull request which disables the auto-adjustments altogether. Conversely to this point about how grouping the controls in the "Columns" wrapper would make the auto-adjustment impact more obvious, I think removing the auto-adjustment and keeping the per-block width controls could at least alleviate some of the current confusion.

@karmatosed

This comment has been minimized.

Copy link
Member

@karmatosed karmatosed commented Jan 6, 2020

I am totally into taking this in steps. I do think it's fair to view together as it shows the cognitive issues, but absolutely this needs to have a solution that scales. Selection is key but that shouldn't force us into adding UI to compensate. It's a tangly problem to work on though so taking it step by step makes sense.

@mapk

This comment has been minimized.

Copy link
Contributor

@mapk mapk commented Jan 6, 2020

It's also good to note it's not a lot of added UI. Those options (outside of the toggle) exist already in other areas. The solution proposed just unifies these elements into a more predictable location.

@karmatosed

This comment has been minimized.

Copy link
Member

@karmatosed karmatosed commented Jan 6, 2020

Whilst yes 'a lot' is in the eye of the person experiencing, for me it was that. By unifying in the way it was it was surfacing in a place that felt more than previously. I totally recognise that was my experience though in what had been done. A note worth considering is when we do these changes to usability test them to check what it feels like outside of us. None of us might be right and that's totally ok as we take it in steps.

@jasmussen

This comment has been minimized.

Copy link
Contributor

@jasmussen jasmussen commented Jan 7, 2020

providing a holistic view that is easily accessible is a plus. Right now having to click through individual columns to figure out their width is a process of "hunt and click". It's a bit daunting to try and remember where these settings are located.

I fiercely agree, this is something to address. But I also feel it is important to separate that conversation from this one.

Specifically, it's about trying to not duplicate UI. Being able to adjust column widths in two different looking interfaces depending on whether the columns block is selected, or whether individual column wrappers are selected, is likely going to add additional confusion: if I can edit in two different looking places, which one is right? And is there a connection between them?

One solution is discussed in #7694, which suggests that the individual column wrappers could be made "passthrough", or invisible. This is somewhat like how Media & Text works, where you don't have to select a column to resize the split. The tradeoff is that you either have to make a complicated UI to set individual padding/background properties for each column, or you just can't.

The alternate route we tried taking in the https://wordpress.org/plugins/layout-grid/ that I worked on. In this version, the interface for resizing columns are the drag handles left and right of each column:

screenshot-2

  • If the main block is selected, handles for all columns are visible.
  • If a column block, or even a paragraph inside, is selected, then handles for only the specific column is visible.

It's technically duplicate UI, but because it visually looks identical regardless of what is selected, it doesn't feel separate.

@karmatosed

This comment has been minimized.

Copy link
Member

@karmatosed karmatosed commented Jan 7, 2020

One point I like from the above screen is it takes away from the sidebar. There really is something about interacting directly. I know there's an issue for the grid and well this is making me feel I'd love it even more across blocks.

@aduth

This comment has been minimized.

Copy link
Member

@aduth aduth commented Jan 7, 2020

Related to direct interaction for columns: #15659, #15927

@mapk

This comment has been minimized.

Copy link
Contributor

@mapk mapk commented Jan 7, 2020

Specifically, it's about trying to not duplicate UI. Being able to adjust column widths in two different looking interfaces depending on whether the columns block is selected, or whether individual column wrappers are selected, is likely going to add additional confusion: if I can edit in two different looking places, which one is right? And is there a connection between them?

@jasmussen, I totally agree there would be confusion if the UI existed in two locations. To help prevent that, I recommended removing those options from the individual Column child block.

Would that help ease your worry? Or just add to it? 😆

@jasmussen

This comment has been minimized.

Copy link
Contributor

@jasmussen jasmussen commented Jan 8, 2020

Sorry, I missed that bit.

This could be a small step on the way, but I can't help but feel like this is just another way to accomplish the same which might just confuse in different ways. So long as the column (singular) is selectable, users might look there and be confused. Your idea here, combined with the passthrough feature, I'd jump on that in a heartbeat, but as mentioned that would come with tradeoffs (no individual padding/background options, or a complex UI for it).

Because of the rabbit hole that is, I do think the very first thing to test, especially since it's likely to be a small PR, would be to remove the auto-redistribution of column widths.

@mapk

This comment has been minimized.

Copy link
Contributor

@mapk mapk commented Jan 8, 2020

Really good thread here – lots of great points! Thank you, everyone.

I too support the idea of the passthrough feature combined with this UI.

  • It surfaces all width parameters together.
  • Presents the widths in a predictable location.

However, this would also move the top, middle, bottom column content alignment to the Columns block as noted by @aduth here: #16370 (comment).

It sounds like the first good step might be to disable the auto-readjustments for now. Then we can take another go on the UI that includes the vertical alignments too, and work toward the passthrough feature.

The individual Column child blocks have always been a bit confusing for me. Especially in light of this bug here: #19354

@joshm33333

This comment has been minimized.

Copy link

@joshm33333 joshm33333 commented Jan 8, 2020

if i was to build my own visual editor, my first instinct would to be have the value set by the user persist in the editor, no matter what. if they dont total to 100, then just use some quick math to get a ratio. for example, user sets 20, 20, 100... then the total is 140... so the output values would be 14, 14, 72.

the key feature here being that the new values are generated on the output, not in the editor, that way you can enter anything, like 1000 1000 3000. not only would it be dummy proof, it would allow for easier math, like 1, 1, 2 would convert to 25, 25, 50

just an idea

it would also be totally backwards compatible

@aduth

This comment has been minimized.

Copy link
Member

@aduth aduth commented Jan 8, 2020

I've opened a pull request at #19515 to experiment with removing the auto-adjustment which happens to a column's siblings when its width is changed.

@aduth

This comment has been minimized.

Copy link
Member

@aduth aduth commented Jan 8, 2020

if i was to build my own visual editor, my first instinct would to be have the value set by the user persist in the editor, no matter what. if they dont total to 100, then just use some quick math to get a ratio. for example, user sets 20, 20, 100... then the total is 140... so the output values would be 14, 14, 72.

It's an interesting idea, but I think it might be difficult to try to communicate this behavior to users in a way that wouldn't be confusing.

For example, what labels would we use for these inputs? Strictly speaking, these aren't percentages, they're just values which end up being considered as relative to the values of a column's siblings.

Even then, considering your example of entering "20", "20", "100".. I think as a user, I might expect that if I entered "20", it would constitute 20%, even if it's fair to say that it can't represent 20% if we want the total to equal 100%. It would be unexpected to me that it would be evaluated as effectively 14%.

@jasmussen

This comment has been minimized.

Copy link
Contributor

@jasmussen jasmussen commented Jan 9, 2020

Moreso than the math becoming hard explain to a user, I believe there is an implicit expectation that if I manually type in a specific number, that number should not be changed without my explicit consent.

Any redistribution could happen as a separate action: "We noticed your columns add up to more than 100%, would you like to redistribute the values to fit? [Yes]/[No]".

@timhibberd

This comment has been minimized.

Copy link

@timhibberd timhibberd commented Jan 10, 2020

#16077 has its advantages. It eliminates all the finicky focus clicking in a busy / constrained focus clicking area that is trying to cover: 1) Select Columns parent 2) Select Column box 3) Select Column box content.

I like the idea of a toggle for manual-fit / auto-fit to 100%. If there is a good case for 200% it could be a combo toggle.

Regarding the auto-fit algorithm, I vote with @phpbits to only auto-adjust the column box to the left / right of the box being adjusted. It yields a result that is in the control of the user.

For a user to get back to a fractionaly proportional symmetry (e.g 1/3 | 1/3 | 1/3) see suggestions in #17918.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.