New settings: Column percentage width

[pinarol]

Let's start to think about how we can introduce Column percentage width settings into mobile.

1. Should we add similar options to the placeholder?

2. Vertically stacked state:

On web, all the columns appear as equal width in this state, so I guess we can do the same. But I am open to suggestions.

3. Horizontally stacked state:

This is the real challenging part. On web, columns are displayed in a single row, so there's a straight forward calculation for the column width there: containerWidth/columnCount. On mobile it is different, we first decide how many column we want to display on a single row. And then we calculate the column width accordingly. So I have 2 options in my mind to adapt "Column percentage width" into this:

A. Keep the current Column width calculation but add a multiplication factor to it.

Let's say we have:

4 columns with equal percentages
Container width is 600 in landscape mode

So, 1 Column width equals to 300.(because we have 2 columns per row no matter what the total column count is)

But, let's say we updated percentage widths as:

1st Column -> 10%
2nd Column -> 40%
3rd Column -> 25%
4th Column -> 25%

Then how do we adjust the widths?

Each Column width = 300*percentageFactor

percentageFactor = percentageWidth/(1/columnCount)

And the widths for each column will be equal to:

1st Column width = 300*(0.1/(1/4))= 120
2nd Column width = 300*(0.4/(1/4))= 480
3rd Column width = 300*(0.25/(1/4)) = 300
4th Column width = 300*(0.25/(1/4)) = 300

B. Don't do anything visual in the editor if columns width change

I think option A is worth investigating.

Any thoughts? @iamthomasbishop @dratwas @lukewalczak

[iamthomasbishop]

1. Should we add similar options to the placeholder?

I think we could probably do something similar, although I would show the options in a bottom sheet instead of on the canvas/placeholder state. For example, when you add the block, we should show the existing initial state, but we could immediately show a bottom sheet that acts as a picker for these layout options.

2. Vertically stacked state:

On web, all the columns appear as equal width in this state, so I guess we can do the same. But I am open to suggestions.

I would show these options in a similar way to how desktop shows them, but explain (via a subtle footer message or similar) that on the mobile editor — especially on phone — columns will be stacked, and they can use landscape, tablet, or desktop preview to get a larger view.

3. Horizontally stacked state:

Perfect timing — I just asked in another comment whether we should open up the 2-column-per-row limitation to 3. That should help a little bit here because I imagine most folks will choose either 2 or 3 columns.

Another thing this work would benefit from is wide and full-width containers, which we don’t have on mobile. I think users are much more likely to select more than 3 columns only when they have a wider container.

I also think Option A is worth investigating. This is a tough problem and I imagine it’s going to take a lot of tinkering to find a balance.

I think this is probably similar to what you’ve got in mind, but let’s use I’d imagine to be a common use case — 4 equal-width columns (25% each) as an example. As a user, I would expect that if I were to adjust the width of any single column, the other 3 columns would adjust from taking up 75% of the width to more or less, and stay equal to each other in terms of their percentages. If I adjust one column to 40%, the others would then take up 60% — or 20% each. I believe this is how the web handles column width adjustments.

I’m excited to work on this! And if our recent work on columns is any indication, it’ll be a fun challenge. 😆

[pinarol]

Perfect timing — I just asked in another comment whether we should open up the 2-column-per-row limitation to 3. That should help a little bit here because I imagine most folks will choose either 2 or 3 columns.

Another thing this work would benefit from is wide and full-width containers, which we don’t have on mobile. I think users are much more likely to select more than 3 columns only when they have a wider container.

We already have the mechanism to arrange the number of columns according to the container width. So when we implement wide and full-width containers it'll just adapt and show more columns. If we want to open up the 2-column-per-row limitation to 3 it seems like a quite straight forward change to me.

As a user, I would expect that if I were to adjust the width of any single column, the other 3 columns would adjust from taking up 75% of the width to more or less, and stay equal to each other in terms of their percentages.

I think we are on the same page 👍

[pinarol]

I think we could probably do something similar, although I would show the options in a bottom sheet instead of on the canvas/placeholder state. For example, when you add the block, we should show the existing initial state, but we could immediately show a bottom sheet that acts as a picker for these layout options.

I find this a bit confusing from a user's point of view. Because they will see the initial columns and then they'll see the bottom sheet. Let's say they'll select 30/70 or 70/30 but they'll observe no changes in the editor. (Since we stack vertically and we already have 2 columns)

Another downside is we are forcing them to make a quick decision as opposed to having these options in the placeholder and letting them choose whenever they want. In case of using the placeholder, I can take a wider look at my page and then decide which one to use.

[iamthomasbishop]

If we want to open up the 2-column-per-row limitation to 3 it seems like a quite straight forward change to me.

Ok, let's try that right away if it's straight forward 👍

Regarding the placement of the columns layout selection (on-canvas in a placeholder vs. in a sheet), I think replacing the current solution (showing the default 2 columns) with inline buttons would feel a bit off. IMO, it would make sense to extend the current implementation and show a picker mechanism when the block is first added — either in a separate bottom sheet w/ just the picker, or to highlight a section in the block settings sheet. If we were to do this, a clear default would be visible, while providing options to customize the layout right upfront. Does that make sense?

This would also map quite well to what I've proposed for a refined insertion process for media blocks such as image, video, etc. — where when you add the block, the placeholder is shown on the canvas while the picker is shown right away. The main difference on columns obviously is that if you dismiss the "picker", you're left with the default 2 equal-width columns (not a bad result, IMO).

I think in the long-term, we will likely come up with a much more dynamic flow for columns customization, such as draggability of columns to adjust the size, drag-to-reorder columns, etc. But for now, I think this would be a nice solution. If you feel strongly about the inline buttons replacing our current starter implementation, I can mock something up.

[pinarol]

Opened a separate issue for increasing the column-per-row limit: #2384

[lukewalczak]

Hello 👋 , I'm starting the investigation from proposed by @pinarol option A with visual changes and percentage factor. Will update you on it!

How would you like to control the column width? I think we can typically use BottomSheet for it and control the width using the slider (the same as spacer height ).

Do we have some mock for placeholder usage?

What should be displayed when user sets 0% width?

[iamthomasbishop]

How would you like to control the column width? I think we can typically use BottomSheet for it and control the width using the slider (the same as spacer height ).

@lukewalczak I think utilizing the existing component is a good start, and I think we will likely keep that setting in the settings sheet indefinitely, regardless of whether we add additional adjustment methods.

With that said, it’d be nice to explore a component that enables on-canvas resizing of elements, which we could also add to other blocks such as Spacer, Image, and others at some point. Whether that should be part of this work or not is a discussion we’ll need to have. // cc @pinarol — what do you think? Do we have the bandwidth to tackle something like a “drag handle” component, one that we could re-use on other blocks?

Do we have some mock for placeholder usage?

I’ve got some rough sketches that I’ll find and drop in a separate comment over the weekend or on Monday!

What should be displayed when user sets 0% width?

I think we might want the smallest value in the range to be 1%, not 0%. Also, I’m imagining any column that is visually ~36px or less will be pretty challenging to select on-canvas. So while 1% might be the minimum value, we’ll need to be mindful of the ramifications when someone changes the column to a very small value.

[pinarol]

// cc @pinarol — what do you think? Do we have the bandwidth to tackle something like a “drag handle” component, one that we could re-use on other blocks?

Actually it'd be great but...
@dratwas @lukewalczak correct me if I am wrong, "drag handle" functionality will be more or less the same with Update Slider to reflect changes immediately. That kind of functionality is currently blocked by #2349. (Huge history there, we first worked on Update Slider to reflect changes immediately and completed the development but couldn't merge because it creates 100 undo levels when user changes the slider 100 units. So we realized we first had to adjust undo level creation logic, and we solved it with this PR. However, that effort surfaced another bug on Android, which is still work in progress. So we can't move fwd before that PR gets merged.)
There was another concern from @dratwas related with animating the ReactNative components this way, because it wouldn't produce very smooth animations. Slider changes will give a good chance to try and see the results.

[lukewalczak]

And the widths for each column will be equal to:

1st Column width = 300*(0.1/(1/4))= 120
2nd Column width = 300*(0.4/(1/4))= 480
3rd Column width = 300*(0.25/(1/4)) = 300
4th Column width = 300*(0.25/(1/4)) = 300

@pinarol I'm wondering how that should apply to case where one column is set to have more than 50%, so its width will be higher than the whole container width.

[pinarol]

@pinarol I'm wondering how that should apply to case where one column is set to have more than 50%, so its width will be higher than the whole container width.

Good point, I think I'd just set the maxWidth to the row width and see if it feels acceptable. We are working on increasing the column-per-row limit to 3, that'll relieve us a bit because the possibility of such a thing happening will be limited to 4 or more columns.

But I am open to other approaches as well, so if you have another thing in mind feel free to try it.

[lukewalczak]

After initial work on that feature, I'm considering an option to set the column width equally to the:
percentage * parentWidth, which means that 100% is a parentWidth and column will take the whole available space.
The reason why I'm suggesting another approach is the result of thinking about the placeholders where with 30/70 or 70/30 variation there won't be any visual effect because the column with 70% will has to take the max-width.

According to that, the screenshot is presenting:

• first row 70/30
• second row 50/50

I know that we are aiming right now in presenting 3 columns, so with the logic above 33/33/33 will show 3 equal columns in one row.

@pinarol @iamthomasbishop wdyt about it?

[lukewalczak]

The only question in that approach is how to present 4 and more columns 🤔

[pinarol]

there won't be any visual effect because the column with 70% will has to take the max-width.

I think we don't have a 100% win scenario here so we'll need to choose between down sides :(

Let's say we have 4 columns: 70% 10% 10% 10%

1st approach would show something like:

|---------------70---------------|
|-10-|-10-|-10-|

The last one you suggested, let's call it the 2nd approach:

|-------------70------------|-10-|
|-------10--------|------10------|

So even though columns 2, 3, 4 have the same width the editor will show them very differently, right?

IMHO not getting any visual effect after 70% feels more acceptable since the user will see it is growing and it has reached the limits. I agree it is not ideal so maybe we should try to compensate with displaying a warning message inside the settings, saying they won't see the effect after 70% and they should check the previews. Just thinking out loud.

[iamthomasbishop]

@lukewalczak @pinarol apologies for the delay, I jotted down some thoughts and responses.

Placeholder/Starter Design

@lukewalczak in terms of placeholder design, I have some sketches and notes regarding the behavior -- I can prep some higher fidelity designs next week. I know there was some earlier discussion about where/how we should display the placeholder content, and I still feel best about not forcing it onto the somewhat limited space on the block container itself. It’d make the most sense to me to show the column-layout picker (which could be styled similarly to the inserter sheet) immediately after the block gets added. The overall flow would look something like this:

Note: I think for the sake of having an "escape hatch" , we might want a "skip" button on the sheet, but the idea is that when we add the default 2-column block to the canvas, we show this sheet.

Editing Column Widths

One thing that I mentioned while talking to @lukewalczak in DM this morning was that there could potentially be a lot of edge cases in terms of number of columns, their widths in relation to how many columns per row we want to support, what happens when certain widths are adjusted in certain directions, etc -- so I think it'd be prudent to utilize what as much as we can from the core side (esp in terms of behavior when adjusting individual columns). There are already some cases where we are adjusting, such as showing 3 columns across on our larger breakpoint, but adjusting column widths can get complex fast.

One place I do think we could improve upon -- and maybe core would want to follow suite -- I would almost always rather adjust column widths on the parent Columns block. My main rationale for this is: when you edit any given column, it affects the other siblings. When you're only able to edit column widths from each individual column block, you easily lose visibility into its affects -- especially on a small screen where columns are stacked.

It might be worth still keeping the width setting on each individual child, but I'd like to see if we can consolidate those settings onto the parent's settings sheet. Here is a sketch comparison between Columns (parent) and Column (child) settings:

Note on setting row styles: I was experimenting w/ an icon style on the slider rows that would essentially visualize/highlight the columns in a way that makes it obvious what you're editing. I wasn't sure if this would be doable, but I think it'd very handy on mobile, where you can't always see the proportions and layout on the small screen.

Arranging 4-column Layouts

Regarding the 70/10/10/10 scenario you described above, I took a look at what the web does, and wonder if we should do the same for now. What happens when you get into the middle break-point (600-781) is it forces 2 equal-width columns.

In our case, we will have a 3-column max, so I think we might want to say 3 equal-width columns in our larger break-point (bc our container is max-580, IIRC). So that'd make our 70/10/10/10 look like this:

I think this would be workable, but I'm curious to hear your thoughts.

Wide/Full-width Alignment Controls

As the discussion continues, I keep thinking about how much we will benefit from having wide and full-width variations of the container (parent aka Columns block). Unlocking this would make working with any row that contains 3+ columns a lot easier (and more representative of the site viewer's experience). @pinarol Is there any way we can prioritize that work in parallel to help with this (and to benefit numerous other issues)?

[lukewalczak]

Thanks @iamthomasbishop for your input!

Mechanism

Before we dive into the starter/placeholder feature, I would like to set some principles for editing column width values. In the beginning, I was convinced to the idea that sum of all columns should be 100%, which is in accord with your mocks, but then I've realized that on the web you can create 4 columns where each of them has 100% width (so the sum is higher than 100%). Then these values we'll have on mobile and there will be a need to present them visually but also present 'percentage' value on slider.

In that way, there is no perfect solution - maybe we should follow the web behaviour, allow each column to have 100%?

Columns presentation

Presenting columns is also tricky, imagine the case where the user decided to have 4 columns 10% width each, so we'll present 3 of them in one row, and 1 will drop although there will be a space for it.

[lukewalczak]

@pinarol If we would like to follow the web behaviour how do we want to then present the columns? Do we want to use the precentageFactor proposed in suggestion A?

[pinarol]

@pinarol Is there any way we can prioritize that work in parallel to help with this (and to benefit numerous other issues)?

I think it is about time we should prioritize it, it is quite useful in homepage layouts. I opened an issue to track it and assigned to you for UX details.

I think we can go like this.

1st iteration(constant width, limited to 3 columns-per-row):

• Add the new columns presets
• Add ability to adjust widths via settings but show no visual clues

2nd iteration:

• Add ability to render all the columns in the same row after a certain width(~800?), and show visual clues. It should match the web behavior this way. We can ship this mechanism but we won't be able to test it properly until we have full-width. I believe we can find some temporary code tricks to test it during PR reviews and revert the trick part before we ship the feature.

When we add wide/full-width support we should go over all the existing blocks and see if they are adjusting well. Hopefully we won't need to do extra work for columns at that point since this would be already handled it in 2nd iteration.

[iamthomasbishop]

show no visual clues

@pinarol Just to clarify, showing no visible changes on the canvas is okay for the first iteration, but we need to make it clear to the user what is happening by showing an informational label or alert of some sort. (something like: Column sizes may differ from what your visitors see. To see a preview of your [post/page], tap on ••• and then Preview.)

2nd iteration:

This all sounds good 👍