Media & Text: Easier resizing

[marekhrabe]

Description

This PR aims to make it easier to resize Media & Text (part of #14410). It adds a new panel to inspector controls called "Layout" which offers a slider to control the Media & Width.

For some users, this might be useful because they can enter specific number manually (currently they can only do that in the code editor). As an alternative to drag & drop in the block itself, this might also help users that have trouble using drag & drop interactions — the slider in sidebar is accessible from keyboard, can be edited using arrow keys and the number input next to it accepts direct number input.

I have also played with an idea to provide several "presets" for widths. They are currently buttons under the range input, which is not their intended style. For now, they are just a first iteration of the idea.

How has this been tested?

Screenshots

Types of changes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[marekhrabe]

I like how Coblocks approached resizing with visually presented layout previews:

And also repeated as block controls:

Looks very similar to Block Styles but I don't think we can use them directly, as they can only change classnames of blocks, not arbitrary attributes like width.

[sarahmonster]

Worth noting that in #14166 we've been discussing the accessibility and use guidelines for the range control component, the results of which may influence your path here.

Do we have data or feedback about how this feature is currently being used? I'd be curious how many users require this much fine-grained control. Maybe we can provide either a range control or a named size control, rather than both? What sort of controls do users need here?

Two other ideas to explore:

• Provide the three preset options as "suggested" snap points (see RangeControl: add tick marks to the track when snapping is enabled #12429) on the range control. We currently don't have a pattern for this though, and to be honest, I'm not sure it would provide a great deal of value.
• Use a radio control and simplify labels. (Media size: "Small", "Half", and "Large" may work better, even though it's a bit less "pretty" than golden ratios, conceptually.)

Given that there are a number of different changes being proposed to the Media & Text block, it may be a good idea at this stage to consider them all holistically from a design perspective, to see how all those pieces work as part of a larger whole. For instance, adding a "Layout" panel here would make for a better placement for the image fill option suggested in #14445.

[kjellr]

Expanding on @sarahmonster's ideas:

The three size options seem a bit analogous to the font size options too — there are a few set sizes, along with a text field for further refinement. We could re-use this pattern here:

I do like the visual aspect of the approach used in CoBlocks too. In this case, I'd probably make it a little clear which section is which. Roughly:

In general though, I think the simpler the better for these controls — and I'd bet that a solution like the font size one is more accessible than any visual/icon option.

[mapk]

I do like the visual aspect of the approach used in CoBlocks too. In this case, I'd probably make it a little clear which section is which. Roughly:

I really like the idea of defining the section, but the Media & Text block can be swapped to have the media on the right. So this may not work too well unless the controls can swap too.

This leaves me with the CoBlocks solution as most desired. I think the icons work well, but we should definitely include text labels for a11y. The wording below isn't quite right, but is a good blend of labels and icons. It uses radio buttons to indicate that only one selection can be made which should be pretty accessible as well.

[kjellr]

I really like the idea of defining the section, but the Media & Text block can be swapped to have the media on the right. So this may not work too well unless the controls can swap too.

For sure — I didn't mention it, but my dream solution would swap the icons to match. 😄 Probably too much work for little benefit though.

[marekhrabe]

I'm happy to make the fancy icon switcheroo if we decide on all those other things 😀

As I read the situation now, it seems like a good idea to add a "Layout" panel, right? Inside the panel, there would be those icon "previews" and short text labels.

I still think it's quite important to have a place where you can actually see the real value as a number (and in an ideal world, you can put any other value there). The case that is now the worst/impossible to handle is when you are making a page with multiple M&T with non-50% size. You can only eyeball that you've made two blocks of the same ratio. If you zig-zag between left/right positions, you are screwed totally.

I agree that slider in the sidebar might not be ideal, as the main content is already a "slider" itself. So what about adding another option which will be "custom" with a simple numeric input?

[kjellr]

Good point, @marekhrabe. Including a text-based custom option here is important. In the sketches above, that control is labeled "Columns". If that's the case, shouldn't this technically be two text fields? Otherwise, it won't be immediately clear which column is being adjusted by the single text field.

If we don't want to add two text fields (I could see the labels for that getting fairly busy + confusing), another solution would be to name this "Media width" or something similar:

... but that doesn't quite work, because with these icons, it's unclear which column is the Media you're controlling. So in that case, I think we'd need to actually go with the fancy switching icons.

[mapk]

As I read the situation now, it seems like a good idea to add a "Layout" panel, right? Inside the panel, there would be those icon "previews" and short text labels.

Yes.

[getdave]

These ideas look really great. Two points that sprang to mind:

1. Icons will almost certainly need to swap to match the layout of Media + Text (ie: Media on left or right) - should be doable as @marekhrabe said
2. Even though it's not selected, the custom input should update to match if you select a preset above.

Look forward to seeing a working version of this 👍

[mapk]

I can see scaling this to the columns resizing as well. With that in mind, I'd like to keep the icons as simple as possible to reflect the columns of the block and not the column's content. Do people still feel this could be done effectively? Or are the two substantially different?

This means keeping the general column icons, we'd need to update the text label instead. Maybe something like:

Also noticed, @marekhrabe that the "more variants" didn't include the icons. Did you need some assets for this?

[kjellr]

Also noticed, @marekhrabe that the "more variants" didn't include the icons. Did you need some assets for this?

In case you do, here are some to try out:

https://cloudup.com/cDFX2x7fJ5Y

[afercia]

Radio buttons + textual labels + icons as visual "hint" seem to me the most accessible option. Note: a similar pattern is used in the Classic Editor > Post Formats meta box.

what about adding another option which will be "custom" with a simple numeric input?

This kind of "compound" controls made of a two form fields where the second field depends on the first one are a bit tricky in terms of proper labelling and keyboard interaction. There are a few similar patterns in core, for example:

Date / time settings:

• the additional input field is always displayed and doesn't have a visible label

Media details modal: Link to custom URL

• the additional field gets revealed only when "Custom URL" is selected
• the field misses a label (this is a bug that should be fixed)

Gutenberg visibility popover:

• the password field gets revealed only when "Password Protected" is selected
• the field has a visually hidden label and a placeholder

Among these patterns, I'd prefer the ones that conditionally reveal the additional field. This would allow to display a visible label. Also, at this point the revealed control could be a range control maybe (with the caveats @sarahmonster mentioned). Very roughly (made it with some copying/pasting 😛), something like this:

[mapk]

I'm on board with @afercia's last mockup. @marekhrabe can you iterate on that?

[marekhrabe]

I'm working on the latest iteration of the design — radio buttons for presets + "custom" option that reveals a slider. Work in progress available now to test.

It's a bit tricky to get the interactions just right. The introduction of "custom" switch adds a layer of complexity as the block itself only stores the ratio as a number. There is no concept of preset or custom so that's something we need to handle purely in the UI layer. I think I got it right now — please try to break it somehow!

Icons were not included (and still are not) because I thought the RadioControl only accepts strings as labels but that's not true and it can contain other things too as I've learned today. I'll add icons shortly.

I've started this PR using golden ratio values as the presets for Small (38%) and Large (62%). Secretly making all sites beautiful by default 🙈 With some of the latest mockups, you've changed that. Should we change that everywhere? If so, what should be in the labels? I liked that those original labels were not specific and shown as a number unless you want to go with custom.

If we go with thirds, what would be the best way to represent them? Is "number slash number" notation the proper and accessible way to describe it or would we be better using a specific unicode symbol like ⅓?

[kjellr]

I've started this PR using golden ratio values as the presets for Small (38%) and Large (62%). Secretly making all sites beautiful by default 🙈 ...

Oh I see! I hadn't noticed that. I suggest we go with thirds by default for a couple reasons:

1. It's easier to explain in a concise label. People will be a little confused why we chose those values.
2. It makes it easier for these to line up with other column-based blocks for now (Columns, Gallery, etc).

Happy to be convinced otherwise though.

If we go with thirds, what would be the best way to represent them? Is "number slash number" notation the proper and accessible way to describe it or would we be better using a specific unicode symbol like ⅓?

I'm not 100% sure. I don't typically see unicode symbols for these sorts of things. My only hesitation would be that I'm not sure all of the system fonts in our font stack include the ⅓ character, which means it might end up showing up in a slightly different font in some cases. Might be better to just use 1/3.

[paaljoachim]

Can we get a status update to where this PR is at currently? Thanks.

[joyously]

Have you tested this with portrait images? or with small images?
See #17787

[draganescu]

@marekhrabe I tried to test this and to rebase it and I had no luck. Testing results in a blank page and a rebase is kinda complex :) should we close this PR or is it something we still want?

[paaljoachim]

It would be helpful to have this feature included. Hopefully this PR and make it's way to the finish line.

[mapk]

If this one is going stale, we should probably just close it out for now.

[draganescu]

Agree with @mapk, will close but can always reopen later as the ideas here are still valuable.

[mtias]

There's also a component that allows specifying units now, so could be used to allow percentages.

[Issa-John]

Maybe we can re-open this? I started working on this a few days because this issue was brought up in the Design channel on Slack. I am just noticing the co-blocks idea, and think it is cool, but I started working before I saw those comments. Attached are some pics of the re-design that I did in Sketch.

[paaljoachim]

Good job, Issa-John! @Issa-John

Here are most of your screens broken into smaller parts.

---

---

---

---

---

I do believe we need to think of a new way to in general create a new resize component. Which can be used in multiple Blocks where resizing would help the layout of multiple elements.

We might even need to look into creating a new resize component issue to be used for multiple blocks. I believe this is a discussion we should have in design. @mapk

[mapk]

Looks like we're getting more movement here agin. Opening it back up to refine the designs and converge on a solution.

[mtias]

Looks like new designs and discussion should be moved to an issue so that it's easier to track.

[Mamaduka]

Hi,

Is anyone still working on this issue/PR? I would love to give it another try.

[paaljoachim]

Hey George @Mamaduka

That sounds great!
I do not believe anyone is currently working on it. I will go ahead and assign it to you.