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

Block-specific responsive controls #13363

Open
mapk opened this Issue Jan 17, 2019 · 58 comments

Comments

10 participants
@mapk
Copy link
Contributor

mapk commented Jan 17, 2019

Problem

Many blocks need to adjust responsively depending on the screen size. Right now block developers are baking in these controls into the block inspector. Let's make sure we provide a unified way to achieve this action.

Solution

Think through ways in which we might implement responsive controls for specific blocks.

Questions

  1. Which should be the default setting for blocks? Desktop, mobile, tablet?
  2. Is it necessary to hide/show blocks based on device width?
  3. Where should the controls go?
  4. Does the theme, the block templates, or the content have precedence when designing mobile styles?

Related to #13203

Issue #13203 is about an overall responsive layout option. This particular issue is focused more on individual block responsive controls.

@mapk mapk added the Needs Design label Jan 17, 2019

@mapk mapk added this to the Future: Phase 2 milestone Jan 17, 2019

@mapk mapk added this to In progress in Phase 2 design Jan 18, 2019

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Jan 21, 2019

I'll share some initial explorations arount this topic.

The block that's most urgently in need of responsive controls at this point is the column block. Currently, columns stack automatically on small screens, without any indication that's going to happen. The Media & Text block also can stack on mobile, but it includes a toggle switch to turn that behavior on or off. This is a great baseline for responsive controls:

screen shot 2019-01-21 at 3 23 41 pm

For many users, this toggle offers more than enough control: it's reasonable to assume that a modern website builder can handle this all automatically if we ask it to. But we should offer some level of fine-tuned control for those users who will want to specify how many columns should appear at various breakpoints.

With that in mind, I built my exploration up around a couple core ideas:

  1. Responsive controls should live in the “Advanced” panel. This panel is currently very under-utilized, but seems like a reasonable home for responsive settings. We should set good defaults, and in most cases the user will never even visit this panel.
  2. Allow for 3 different options:
    A. Our smart default: Stack columns on mobile.
    B. Use the same number of columns everywhere.
    C. Specify column counts for mobile, tablet, and desktop screen sizes.

With those in mind, I built a couple prototypes:

Desktop Prototype (Figma)
Mobile Prototype (Figma)

Screenshots for reference:
screen shot 2019-01-21 at 3 39 34 pm

screen shot 2019-01-21 at 3 42 44 pm

As you’ll notice when you click through: when you have option (C) selected, the only device options shown in the “Devices” panel are the devices you’re not using. If you’re on a phone, the default slider under “Columns” will control the number of columns you’d see on a mobile device. If you keep option (C) selected and access this block from a desktop machine, the default slider will control the number of columns you’d see on a desktop view. This prevents duplicating controls that do the same thing, but I'm not totally sure whether it’s intuitive or confusing. An alternative would be to show all devices down there, and disable the default slider when option (C) is selected, but that seemed weird to me.

I'm Interested in some feedback! I'm also curious how these sorts of controls might extend to other types of settings: What other blocks would benefit for responsive controls like this?

@mattbolt

This comment has been minimized.

Copy link

mattbolt commented Jan 22, 2019

I've been building a rather large theme recently for a work project launching in the next couple of weeks. I thought I should probably shared some of my thoughts. The following panel is what I've implemented for handling stacked columns on various devices. Each Device can have it set explicitly and also have the order reversed. (Using flex for columns css).

image

The top portion (margin / padding) is also available on all blocks. Allowing us to create some pretty fantastic layouts entirely from the editor.

What I would love to see is desktop/tablet/mobile buttons available at the top of the editor to switch the editor into the respective modes without resizing the window. This would allow for very rapid building for all response levels. While those three modes work for my purposes, potentially a range of response levels could be configured in the theme allowing you to switch between any of them.

As we no longer have an iframe based editor, this is clearly going to take a bit more trickery to pull off. Having thought a bit about how I could accomplish something similar, I would imagine that the editor could not use media queries, and instead css would need to be developed specifically for the editor for every block. I'm currently doing this anyway for my own theme. If the "editor-styles-wrapper" div had the current response added to the class, you could easily substitute media queries for class based responses.
eg: .editor-styles-wrapper--mobile { }

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Jan 22, 2019

What I would love to see is desktop/tablet/mobile buttons available at the top of the editor to switch the editor into the respective modes without resizing the window. This would allow for very rapid building for all response levels. While those three modes work for my purposes, potentially a range of response levels could be configured in the theme allowing you to switch between any of them.

Thanks for sharing, @mattbolt. In case you haven't seen it, we're discussing that exact sort of thing right over here: #13203

As for the responsive margin/padding rules: I'd love to see more fine-tuned controls for margin + padding. But for the majority of users, I imagine those would be more beneficial on a global level. That's why I left them out of my explorations above. I do think we should definitely include margin/padding controls somewhere, but per-block seems a little too granular to me (at least for core).

@LevinMedia

This comment has been minimized.

Copy link

LevinMedia commented Jan 23, 2019

heya @mapk @kjellr - I left a comment on #13203, but I think it's worth highlighting a portion of it in this issue as well.

This is the latest prototype we're working on - It's based on feedback we got from our recent usability test that I noted in #13203.

screen shot 2019-01-22 at 9 56 10 pm

Figma

Our blocks have a few different settings, and not all of them should be editable on a device by device basis. As such, we think placing responsive controls in individual settings makes sense. In the example above, the responsive controls for layout can be adjusted, but filtering by category can't. (filtering by a category should always apply to all device sizes) We'd also want to use smart defaults, so folks wouldn't have to go in and adjust the layout for each device size.

The first portion of our test was run using live blocks which didn't feature any responsive layout controls. Many of our participants asked questions along the lines of, "How do I change these layout settings for mobile devices?" It leads me to belive that more people are going to want this kind of granular control than we think.

Putting responsive controls in the advanced settings is another option, however, I belive it would make it more difficult to find... granted that's a bit of a one time problem - once you find it, you know where to look for it the next time. That said, I also think there's something to keeping responsive controls in the context of the setting that a user is adjusting as well.

We haven't had a chance to test this latest version, but we hope to soon.

@mapk

This comment has been minimized.

Copy link
Contributor Author

mapk commented Jan 24, 2019

@kjellr

I'm Interested in some feedback! I'm also curious how these sorts of controls might extend to other types of settings: What other blocks would benefit for responsive controls like this?

I really like how you took something so complex and simplified it in a usable way for anyone to understand. Another block that could benefit is the Gallery block which already has some rudimentary column adjustment settings.


@mattbolt

The top portion (margin / padding) is also available on all blocks.

Thanks Matt! Your exploration into margins and padding is a good one to share here as well. #11824


@LevinMedia

Many of our participants asked questions along the lines of, "How do I change these layout settings for mobile devices?"

Really interesting!

That said, I also think there's something to keeping responsive controls in the context of the setting that a user is adjusting as well.

This makes sense in context to the Woo block that also allows adjusting the product number as well. Do you think it's necessary when there's only one adjustment (ie. columns) as in @kjellr's mockups?

@ZebulanStanphill

This comment has been minimized.

Copy link
Contributor

ZebulanStanphill commented Jan 28, 2019

I'm noticing that most of the mockups so far use icon-only controls. Ideally, for accessibility (and general usability), it would be best if the responsive controls had visible labels. I'm not sure how feasible this is, but I just wanted to point it out, since Gutenberg has struggled with accessibility in various areas, and it would be a good idea to try and avoid adding any more icon-only UI.

@jameskoster

This comment has been minimized.

Copy link

jameskoster commented Jan 28, 2019

Another thing we'll need to consider is toolbar options that might require responsive settings. For example the block width feature found on the Cover block. You might want narrow width on desktop and full-width on mobile.

@LevinMedia

This comment has been minimized.

Copy link

LevinMedia commented Jan 28, 2019

Heya @mapk

Do you think it's necessary when there's only one adjustment (ie. columns) as in @kjellr's mockups?

I do. Discoverability is a big part of that reason for me. It puts the responsive settings directly in the context of the setting(s) that are being manipulated.

I think there are going to be many cases where a block has multiple responsive settings, and not all of them are going to fit neatly in a single bucket like, layout.

For example, your second question above.

Is it necessary to hide/show blocks based on device width?

In my previous usage of page builders, the answer to that question has been yes. Adding a "Visibility" settings with it's own responsive controls would allow for that.

screen shot 2019-01-28 at 11 05 58 am

@LevinMedia

This comment has been minimized.

Copy link

LevinMedia commented Jan 28, 2019

In hindsight - Visibility might not be the best example in this case, as something like that would probably be better suited as simple list of toggles.

[toggle] Show on desktop
[toggle] Show on tablet
[toggle] Show on mobile

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Jan 28, 2019

Many of our participants asked questions along the lines of, "How do I change these layout settings for mobile devices?"

@LevinMedia I wanted to followup on this finding: can you share any more details about the pool of users who were part of this test? This finding surprised me a bit, so I'd like to learn more. Thanks!

@jameskoster

This comment has been minimized.

Copy link

jameskoster commented Jan 28, 2019

I think a key consideration here is our expectation for how much of an impact responsive manipulation will have on the overall authoring experience. Not only now but in the future as well.

Which should be the default setting for blocks? Desktop, mobile, tablet?

That question is top of mind for me right now. I like @kjellr's design a lot for the reasons @mapk mentioned above, but I'm not sure how well it would transition to a "mobile first" experience?

As @LevinMedia said, most participants in our recent usability tests showed a keen interest in mobile settings already and declared it to be "very important" to them. Of course it must be said that there is some bias there as each participant was a WooCommerce user and perhaps more "tech savvy" than other users.

My inclination at the moment is to agree with @LevinMedia - context will be vitally important here. I think it should be very easy for users to find these settings and understand what they do.

On a related note, I personally do not like the "Advanced" section of the settings panel - for almost any use case. It feels arbitrary to me and I've literally no expectation what settings I might find in there when first interacting with a block.

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Jan 28, 2019

That question is top of mind for me right now. I like @kjellr's design a lot for the reasons @mapk mentioned above, but I'm not sure how well it would transition to a "mobile first" experience?

Along these lines, one of the considerations in my approach above is that it's aware of which screen you're editing from. In other words, the device you're on is the one you're designing for "first". If you visit from a mobile phone, the only slider you'd see in the main area is the mobile slider. The rest are down in Advanced. Or, if you visited from a tablet: the tablet would be shown as the default control, and the others would be down below. This could very well end up being confusing: splitting the controls between the regular sidebar panel and Advanced feels a bit off to me, as I mentioned originally in my notes above.

But in general, I do like the general idea of being device-aware. In the mockups @LevinMedia posted, that'd equate to defaulting to selecting the mobile tab when visiting on a mobile device, or to tablet when you're visiting from tablet, etc. (I actually think I saw that in one of your mockups, but I can't find it now.)

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Jan 29, 2019

Spent a little bit of time thinking through a slightly different direction for this. One thing that hasn't quite sat right with me from my previous iteration was how I separated out the columns controls between the main sidebar "Columns" panel and the "Advanced" panel.

This exploration simplifies the options a bit and moves everything back into the main "Columns" area:

responsive-new

🖥 Desktop Prototype

📱 Mobile Prototype

The first frame just adds the "Stack on mobile" toggle we currently have available to the Media & Text block. By default, it's turned on, and everything's handled automatically. This is the best setting for users who do not want to manage these settings. Unlike today, if a user were to toggle that off though, they'd be presented with more fine-tuned controls there instead. From here, they can either leave it alone (it'd default to the same size for each), or adjust to set a different column count for each device type.

Some considerations:

  • Generally, this needs better labeling + descriptions.
  • This works fine for one option, but it wouldn't scale well if there were multiple settings per breakpoint.
  • We don't typically show/hide controls based on toggle switches being turned off. Not sure if that really makes sense here.
  • Related to the above: hierarchy-wise, it seems weird to have a toggle switch affect the fields above it. It'd may be more natural to lead with the switch in this case. That also wouldn't feel right though, because the primary thing people will want to do here is adjust the column count not toggle responsive controls.

One question I keep coming back to as I'm exploring and reading through the thoughts here: how simple or complicated should this be in core? Some custom blocks will include certainly include a ton of individual settings for each breakpoint: margin, padding, showing + hiding blocks, etc. That may be what their user base is comfortable with. But we don't necessarily want to include that level of control in the default blocks since it may be overwhelming for a novice user. That said... it's likely beneficial for us to establish design patterns that can scale up to those super-complicated scenarios, so that we can help demonstrate how this should be handled in all cases. How can we define a simple pattern that scales between people who do not want to have to manage responsive settings and those who want to be really specific about these things?

@ZebulanStanphill

This comment has been minimized.

Copy link
Contributor

ZebulanStanphill commented Jan 29, 2019

Nice mockups, @kjellr!

Generally, this needs better labeling + descriptions.

At the very least, the device icons should be moved to labels for each of the sliders, e.g. "🖵 Desktop".

This works fine for one option, but it wouldn't scale well if there were multiple settings per breakpoint.

I think the answer to this lies in the toggle. What if every responsive control had a toggle to enable/disable customizing the responsiveness of the setting? Divi Builder has something pretty similar to this.

Related to the above: hierarchy-wise, it seems weird to have a toggle switch affect the fields above it. It'd may be more natural to lead with the switch in this case. That also wouldn't feel right though, because the primary thing people will want to do here is adjust the column count not toggle responsive controls.

I think I would prefer having the toggle above the sliders, since toggling it affects the sliders.

But we don't necessarily want to include that level of control in the default blocks since it may be overwhelming for a novice user.

I think that a lot of stuff could be hidden behind toggles like the ones in your mockup by default, or by simply keeping them in closed accordions by default. Margin and padding could both be in the same accordion, and you could toggle responsiveness for those controls with toggles like in your mockup. I don't think this would overload the user with options if this accordion is placed below all the more common options and is closed by default.

@LevinMedia

This comment has been minimized.

Copy link

LevinMedia commented Jan 29, 2019

@kjellr - Following up to Jay's comment. We had a small sample size (eight participants) so as I mentioned before, more testing/research is definitely warranted.

All of the participants came from the WooCommerce Design Feedback Group - As jay mentioned, our participants, and this group of participants in particular skewed heavily towards the more experience builder / Store Assembler profile, rather than a DIY shop owner.

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Jan 30, 2019

A small followup to the mockup I posted yesterday:

frame

🖥 Desktop Prototype

📱 Mobile Prototype

After taking through it with @jasmussen and some other folks, I tried using a ButtonGroup instead of a Toggle, alongside some (hopefully) clearer copy. Changing the formatting and copy this way allows us to more naturally place the control on top of the columns control. That feels a lot more expected hierarchically.

One thing I really like about this approach is that it sets the precedent that, these controls should be handled by the block by default. Block designers will have infinitely more control than users will, since they'll be able to define their own breakpoints. Block designers will also have a lot more experience with responsive design than many users, and should be able to apply best practices here.

Also, if a user switched to manual, made a bunch of adjustments to breakpoint settings, and messed things up, the "Auto" option is a quick escape hatch for them.

There are still some weird things to sort out here (for instance, who chooses these exact breakpoints?). But this seems like the sort of setting that may be able to scale to more complicated setups, and I think we're getting closer.

@jasmussen

This comment has been minimized.

Copy link
Contributor

jasmussen commented Jan 31, 2019

Love it, Kjell. It allows a default that is best in most cases, yet granularity for those who want it. It also feels like a pattern that can scale from the columns block, to other blocks, to even third party blocks. Well done.

@karmatosed karmatosed added this to To Do in Phase 2 via automation Jan 31, 2019

@karmatosed karmatosed removed this from In progress in Phase 2 design Jan 31, 2019

@karmatosed karmatosed moved this from To Do to In progress in Phase 2 Jan 31, 2019

@ZebulanStanphill

This comment has been minimized.

Copy link
Contributor

ZebulanStanphill commented Jan 31, 2019

Very nice, @kjellr!

I still think that each of the sliders should have visible textual labels for accessibility and clarity reasons, but other than that, I think we're getting close to being able to actually implement this functionality!

Also, in terms of accessibility, are we sure a button group is more appropriate than a toggle in this context?

@jameskoster

This comment has been minimized.

Copy link

jameskoster commented Jan 31, 2019

I like these concepts and they work well for columns but I see some small issues with both.

The concept with the toggle is my favorite of the two, but it won't be consistent across settings as the label will be different each time. So it won't be immediately obvious that the setting has mobile options. I worry about scalability.

The concept with the segmented control feels a little odd to me because you're asking the author to make a choice of auto vs manual before actually interacting with the column setting. That's not what I'd expect to see when opening a "columns" section in the settings. The labels don't feel particularly clear to me either.

I'm keen to hear more thoughts around the concept @LevinMedia shared earlier. We came to that solution after a round of usability testing and it seems fairly consistent with what other block authors are doing. Is there a reason we're discounting that approach?

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Jan 31, 2019

I'm keen to hear more thoughts around the concept @LevinMedia shared earlier. We came to that solution after a round of usability testing and it seems fairly consistent with what other block authors are doing. Is there a reason we're discounting that approach?

Sure! I don't meant to discount that solution. The key thing I see missing from that direction is the presentation of a "let us handle it" option. While more advanced users will jump right in and edit everything under each of those device icons, that'll be a lot of work for a notice user. Especially when we could just handle it automatically for them.

Aside from that, the crux of that direction is the segmented control for devices:

screen shot 2019-01-31 at 11 41 00 am

I think works fairly well and could be a pattern to use here, though if we incorporated a segmented control above it that could get weird.

@jameskoster

This comment has been minimized.

Copy link

jameskoster commented Jan 31, 2019

The key thing I see missing from that direction is the presentation of a "let us handle it" option.

Gotcha. So the concern is that the tablet / mobile toggles don't feel optional? That makes sense. But I feel the device segmented control would provide a more consistent pattern across different setting types and therefore scale better. Ease of use vs. Consistency and scalability is a hard one!

To stress test these concepts a little more might I suggest adding another option beneath columns, that would also have a responsive component: Rows.

@jameskoster

This comment has been minimized.

Copy link

jameskoster commented Feb 6, 2019

I see no reason to not just use a toggle labeled "Use custom device-specific layout" or something like that that is disabled by default. Additional text describing the current state could be shown below the toggle, similar to some existing toggle controls in Gutenberg.

I'm going to +1 this.

My main gripe with the Segmented Control is that it looks like two options, which increases perceived complexity 100% vs a single toggle. The author has to understand two settings rather than one.

As the toggle can have a more detailed label that makes it even easier to understand. It's seems a case of one setting with a very clear explanation vs two settings with a more ambiguous explanation. There's a clear winner there imo.

However, I would consider that the toggle be on by default and set the label to something like "Automatically configure layout for other screen sizes". My reason being that this is something we're presenting as a "smart default" that is enabled by default. To me it feels like something you opt out of. Like removing training wheels or disabling ABS.

@jasmussen

This comment has been minimized.

Copy link
Contributor

jasmussen commented Feb 6, 2019

I'm really impressed with your process, here, Kjell — you are positive and open-minded about this, a model productive contributor ❤️, and you leverage existing patterns and UI controls.

I recall seeing you (I can't recall where, private DM?) creating a toggle-version of this also, and that you explored using the ButtonGroup to actually improve usability and accessibility. Perhaps it would be worth posting that mockup here as well?

I don't personally have a preference for which version we might set out to the tumultuous review sea, but given the recent mentions of toggles, seems like it might be worth showing that as an option also.

The buttongroup works well for the Image dimensions especially because each item in the group are distinctly related:

buttongroup

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Feb 6, 2019

Thanks as always for the feedback. 👏


@afercia

Properly labelling and encouraging participation would be greatly appreciated

Of course! This thread has been so active, I haven't scrolled up to look at the labels in weeks now. Thanks for adding the Accessibility label, and welcome to the discussion.

At this point: what is the argumentation to not use native radio buttons, which are the proper elements to be used for a single-choice option?

I tried that earlier, but didn't share the exploration:

idea 2 - sidebar a 1 1 1

Here's why I passed it over personally:

  1. The radio controls take up a lot of space, and I don't think they're much clearer. A goal here is to make this appear simple — most people should be able to gloss over this setting and let us handle it.
  2. Our guidelines for the RadioControl suggest that "To toggle a single setting on or off, use the ToggleControl component." This is a single setting, so some sort of toggle seemed more appropriate.
  3. I've been looking to Material for patterns to use here. I've been unable to find any examples of radio buttons triggering the showing/hiding of additional controls. I have found some examples of toggles doing that, however.

@jasmussen

I recall seeing you (I can't recall where, private DM?) creating a toggle-version of this also, and that you explored using the ButtonGroup to actually improve usability and accessibility. Perhaps it would be worth posting that mockup here as well?

Yep, I shared that with you in DM while talking through this. Here it is:

toggle

I also whipped up a desktop prototype for this approach.

I was torn between these two solutions. Following our own guidelines, a ButtonGroup is used to “group any related buttons together”, and our standard FormToggle “switches a single setting on or off”.

Solely based on those brief descriptions, I thought the FormToggle made more sense. But it was more or less a toss up between the two approaches.

The main thing that the ButtonGroup had going for it was the fact that it allowed us to more clearly label both states (Auto, Manual). The wording for this is really confusing, so that seemed like a plus. I could totally be convinced otherwise, and both are worth testing.

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Feb 6, 2019

Oh also, responding to myself from up here:

Another thing that came up while chatting about this problem with others is the link between making a setting for another device, and previewing that change. Perhaps there's somewhere we can include a link to a device-specific preview in this area (in the vein of #13203).

I did a quick exploration of how this might look, thinking about the preview inside of a modal:

screenflow

This seems kind of fun, but may also be out of the scope of this issue.

I'm also not really into my "only on hover" treatment of the preview icon. I tweaked it a bit when trying this out on mobile:

mobile

@jasmussen

This comment has been minimized.

Copy link
Contributor

jasmussen commented Feb 6, 2019

Really dig that responsive preview. I've been doodling along the same lines in spare time, with simply replacing the preview button with that:

screenshot 2019-02-06 at 15 27 21

👆 but that needs more time in the oven, please don't consider it even a proposal. Just a seed of an idea to throw in the mix, to grow into something actual.

@ZebulanStanphill

This comment has been minimized.

Copy link
Contributor

ZebulanStanphill commented Feb 7, 2019

I tweaked one of @kjellr's neat mockups to be more accessibility friendly by adding labels to the device icons and a "Column count" label to the group of sliders. (Is that last one necessary, @afercia?)
responsive-controls-mockup

One thing I'm not sure of is how the breakpoint widths are defined. Are they provided by the theme or the block? Can a block choose to have just 2 breakpoints instead of 3? What about 4? What about custom breakpoint widths? Whatever the case, I don't think the editor should be providing them.

This kind of ties into what @m-e-h was talking about in this comment. I'm starting to lean towards something similar to what he suggested at the end of that comment. I imagine that responsive controls for columns could be implemented with just 2 sliders:

Minimum column width
―――――o―――― [300] px
Maximum columns per line
―――o―――――――― [__3]

This seems a lot simpler and far more "responsive" to me, without having to resort to hard breakpoints based on average device screen widths.

@afercia

This comment has been minimized.

Copy link
Contributor

afercia commented Feb 9, 2019

A goal here is to make this appear simple

@kjellr sure and thanks for the clarification. However, controls should not only appear simple. They also need to be semantically correct to support assistive technologies. For example, they need to be announced in a meaningful way by screen readers. Imagine a screen reader user tabbing through focusable controls: at some point the screen reader would announce:
"Auto"
"Manual"
without any context whatsoever: what "Auto" and "Manual" refer to?

Instead, radio buttons grouped in a fieldset with a legend do give context because the legend is announced.

As a general rule, native form controls already provide what's needed for semantics and accessibility. Instead, custom controls often destroy the expected semantics and interaction.

It's really important for designers and developers to understand that when implementing custom controls, extreme care should be taken to rebuild all the features of the equivalent native control.

In this case, this is a single choice between two options. Buttons are not appropriate. Radio buttons grouped in a fieldset with a legend would be ideal. A toggle could be an acceptable trade-off if we change the meaning of this control from a single choice between two options to an "on/off" switch, which is comparable to a single checkbox (with all the caveats discussed at length about toggles in previous issues).

Re: Material design: I'm not sure it necessarily needs to be a source of inspiration for a project like WordPress that aims to be as accessible as possible 🙂 Many of the Material patterns are largely inspired by mobile user interfaces and there's a long way to go for those patterns to be fully accessible.

@oldenwilde

This comment has been minimized.

Copy link

oldenwilde commented Feb 11, 2019

Besides Columns, I'm encountering the need for a "stack-on-mobile" option for Image blocks. The legacy website I'm migrating to Wordpress Twenty Nineteen has plenty of left- and right-floated, text-wrapped images that are (and need to remain) 300px or so in width. Dropped into a Paragraph block, these Image blocks work fine on desktop, but on most mobile screens they squeeze the text next to them into illegibility. For each image, I'm having to use the Advanced panel on the Image block to add a CSS class .isom (quicker than typing "is-stacked-on-mobile"!) that expands the image to 100% width for the breakpoint Twenty Nineteen uses. I would think this might be a common problem for many users, and not just migraters (if that's a word).

Just a suggestion, since I'm not familiar enough yet with Gutenberg to proffer a solution.

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Feb 13, 2019

Thanks for the continued feedback, everyone!

One thing I'm not sure of is how the breakpoint widths are defined. Are they provided by the theme or the block? Can a block choose to have just 2 breakpoints instead of 3? What about 4? What about custom breakpoint widths? Whatever the case, I don't think the editor should be providing them.

In general, breakpoints would be specified by the block author. I chatted with @jasmussen about this recently, and we agreed that it makes sense for Gutenberg to provide a handful of defaults to start with (perhaps these are mapped to the default breakpoints that Gutenberg uses), but that we should give block authors the option to opt in or out of those, as well as to add more if the specific block requires them.


It seems like people are more or less gathering around using a standard toggle control in this case.

I've done a bit of light cleanup to @ZebulanStanphill's comp above, adjusting spacing and type hierarchy. Since we're already using text weight to differentiate the panel titles from the individual field labels, I've gone with a color adjustment for the individual device labels. The gray for those is $dark-gray-300, which passes AA.

Here's an updated mockup and prototypes:

frame

🖥 Desktop Prototype

📱 Mobile Prototype

I've also gone ahead and mocked up some alternate cases:

In the interest of moving things along, here's what I'm thinking:

  1. Get another round of feedback from everyone in the thread. I'd love to hear specifically from an a11y perspective: whether or not this seems like a solid solution.
  2. Gather some alternate labels. The label for the toggle field is still a bit confusing. We should generate a few more options and then:
  3. Do some light user testing of the labeling to see which ones properly set expectations for this functionality.

Please let me know any thoughts on this direction, and on those next steps!

@ZebulanStanphill

This comment has been minimized.

Copy link
Contributor

ZebulanStanphill commented Feb 13, 2019

@kjellr

Since we're already using text weight to differentiate the panel titles from the individual field labels, I've gone with a color adjustment for the individual device labels. The gray for those is $dark-gray-300, which passes AA.

Personally, I would prefer a darker gray, just to be safe. The labels seem a bit weird being that lightly colored.

A more complicated example (I think some of the labeling in the bottommost section here could be consolidated.)

Yeah, there's no reason for the labels above each toggle. The icons could just be put next to the toggles before the toggle label.

Also, this is just a nitpick, but shouldn't those sliders stretch all the way to the left, rather than appearing to be indented from the breakpoint labels?

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Feb 13, 2019

Personally, I would prefer a darker gray, just to be safe. The labels seem a bit weird being that lightly colored.

Going a little darker is fine. I wouldn't go darker than $dark-gray-500 though (pictured below), otherwise the gray ends up looking very similar to the rest of the text.

screen shot 2019-02-13 at 1 18 27 pm

Also, this is just a nitpick, but shouldn't those sliders stretch all the way to the left, rather than appearing to be indented from the breakpoint labels?

I indented them to add a bit more hierarchy to the fields. When each field is full-width, it's less clear that these are subordinate to the "Number of columns" label.

@ZebulanStanphill

This comment has been minimized.

Copy link
Contributor

ZebulanStanphill commented Feb 13, 2019

@kjellr

I indented them to add a bit more hierarchy to the fields. When each field is full-width, it's less clear that these are subordinate to the "Number of columns" label.

In that case, wouldn't it make sense to indent the breakpoint labels as well?

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Feb 13, 2019

In that case, wouldn't it make sense to indent the breakpoint labels as well?

Sort of, but we don't typically indent things. Doing so here looks unintentional/broken to me:

screen shot 2019-02-13 at 3 36 40 pm

Here's the comp with full-width fields too, for comparison:

screen shot 2019-02-13 at 3 37 24 pm

As I noted above, that eliminates some of the visual hierarchy and seems less scannable at a glance to me. Indenting just the fields seemed like a good compromise:

screen shot 2019-02-13 at 3 41 59 pm

@mapk

This comment has been minimized.

Copy link
Contributor Author

mapk commented Feb 14, 2019

I really like the layout with indenting just the fields. This appears to address the a11y issues, and agree on getting some feedback there.

My only real concern is in the "complicated example" shared. This is where I feel the design doesn't work as well. Once there are two things that require responsive controls (ie. columns & number of products), all those icons and labels become a lot for me to parse. On the good side, it's structured well enough that I'm still able to parse it. 😉

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Feb 14, 2019

My only real concern is in the "complicated example" shared. This is where I feel the design doesn't work as well. Once there are two things that require responsive controls (ie. columns & number of products), all those icons and labels become a lot for me to parse.

I fully agree there. On previous expirations that didn't have labels, I felt that these were still mostly digestible:

export

... but the new version is pretty hard to scan when it gets complicated. One possible way to improve this would be to adopt adopt the following ideas:

  • Recommend consolidating multiple controls under the same device section (as shown in the Layout section below).
  • Eliminate device labels when the control's label can state the device name instead (as shown in the Visibility section below).

The first one I feel good about. Not so sure about the second, as I think it'd be hard to nail down best practices around it.

frame 2 1

@afercia

This comment has been minimized.

Copy link
Contributor

afercia commented Feb 14, 2019

I'd recommend to think in terms of semantics first, and then design around the required semantics.

Each input needs to be labelled in a meaningful and unique way. Those text label will be <label> elements associated with the sliders and the number fields. As a user of assistive technologies, how am I supposed to distinguish multiple fields all labelled with the same text?

For example:

  • as a screen reader user, tabbing to the various number fields I'll hear "Number of columns" for multiple fields without a clue what they refer to (desktop, mobile?)
  • as a speech input user, voicing a command "Click Number of columns" will confuse the voice recognition software I'm using, as it won't be able to distinguish between fields with the same name

There are workarounds users can use but forcing them to explore what is around the fields or to use alternative methods to navigate content is less than ideal.

All these labels need to give better context and need to be unique for each field.

This interface is complicated, I'd recommend to explore a way to radically simplify it. For example:

  • I'm not sure what is the value added by the sliders, other than their "prettiness": they're difficult to use even with a mouse, they take a lot of space, and there are already input fields
  • not sure the device icons are really necessary: removing them could save some space

Glad to see the "Auto" and "Manual" buttons are gone in the last prototype and they've been replaced with toggles (although toggles have their own problems). Thank you.

@m-e-h

This comment has been minimized.

Copy link
Contributor

m-e-h commented Feb 14, 2019

So the Visibility settings is to hide the entire block for certain devices? Would this be added as an option for every block? Buttons, Paragraphs, Separator , etc?

I'm not a fan of the practice personally but I suppose there are still use cases that can't get around it.
Are there enough use cases though? Or are we assuming that other page builders do it so it must be needed?

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Feb 14, 2019

So the Visibility settings is to hide the entire block for certain devices? Would this be added as an option for every block? Buttons, Paragraphs, Separator , etc?

Oh, sorry for the confusion there: That's just an example of stress-testing this pattern for different circumstances (it was raised in the context of a 3rd party Products block above). We won't be adding that to any core blocks.

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Feb 14, 2019

Thanks for the input, @afercia! I appreciate your feedback here.

As a user of assistive technologies, how am I supposed to distinguish multiple fields all labelled with the same text?

My thought was that the parent header for each of those sections (Desktop, Tablet, Mobile, etc) would be the key to telling them apart, but I'd been anticipating that from the perspective of someone tabbing through the controls. If someone were instead using voiceover (for instance) and tapped directly onto one of the child controls, I can see how that'd be confusing.

It sounds like we'd be best served by having each label be distinct and clear. I don't know that this is the right solution, but for illustration purposes, is something like this what you're suggesting from a labels perspective?

frame 2


  • I'm not sure what is the value added by the sliders, other than their "prettiness": they're difficult to use even with a mouse, they take a lot of space, and there are already input fields

In this case, we're just reusing the slider control that's used on the default state of the block. If we were going to remove the slider, I'd imagine we'd want to do so for both the "Auto" responsive settings and for the manual per-device settings. But that seems like it's the start of a larger discussion around the usefulness of sliders in general, and I'm not sure this ticket is the right venue to address that in.

In any case — this is meant to start defining a reusable pattern for responsive block settings, so while removing the slider may help us in this case, there are likely other situations where the slider would still be used.

  • not sure the device icons are really necessary: removing them could save some space

I'd prefer to keep the icons in, as I think they're a helpful visual reference point. Especially with the indented fields in my latest comps, the icons stand out as quick visual markers in a sea of text and controls. This benefit will be strengthened even more if we end up adding more text to the labels.

@mapk

This comment has been minimized.

Copy link
Contributor Author

mapk commented Feb 15, 2019

@afercia

I'd recommend to think in terms of semantics first, and then design around the required semantics.

If the HTML was written accordingly using fieldset, legend and so on, would @kjell's layout work with screenreaders? I believe the fieldset grouping makes sense in this case. This is new to me, so I could be wrong.

screen shot 2019-02-14 at 4 25 54 pm

@afercia

This comment has been minimized.

Copy link
Contributor

afercia commented Feb 15, 2019

It sounds like we'd be best served by having each label be distinct and clear.

@kjellr yes :) I'd consider to have each label giving context as in your example. That's simpler and more understandable. Maybe a slightly shorter wording might help. For example, is "Number of" really needed? I'd say also visually there's a lot to process and maybe simplifying things might help a bit.

@mapk yep, I've considered that. fieldset and legend are the right way to group together a set of controls and give the group a name. It's a matter of actual support though, and would need to be tested. It works pretty well with groups of radio buttons or checkboxes. I don't know if it works well with range and number inputs.

The RangeControl component has one more issue: the same label value is used for both the range and the number inputs. Thus, the range and the number input have the same accessible name. Not ideal. Will propose to discuss later today during the accessibility team meeting (everybody's welcome to join).

@m-e-h

This comment has been minimized.

Copy link
Contributor

m-e-h commented Feb 15, 2019

same label value is used for both the range and the number inputs

I'm hoping to change that with #13863 @afercia

@afercia

This comment has been minimized.

Copy link
Contributor

afercia commented Feb 15, 2019

Thanks @m-e-h! I've quickly commented there.

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Feb 18, 2019

@kjellr yes :) I'd consider to have each label giving context as in your example. That's simpler and more understandable. Maybe a slightly shorter wording might help. For example, is "Number of" really needed? I'd say also visually there's a lot to process and maybe simplifying things might help a bit.

Thanks, @afercia. Here's a mockup of that:

frame 2 2

The "Columns on" part of the field label seems a little repetitive after the "Number of Columns" label to me. But I think it's workable.

yep, I've considered that. fieldset and legend are the right way to group together a set of controls and give the group a name. It's a matter of actual support though, and would need to be tested. It works pretty well with groups of radio buttons or checkboxes. I don't know if it works well with range and number inputs.

How can we verify whether it works with range and number inputs? If this labeling issue is covered already this way, I'd prefer to keep the individual field labels more concise.

@m-e-h

This comment has been minimized.

Copy link
Contributor

m-e-h commented Feb 18, 2019

I think the "Columns", "Items", etc. part is helpful with the device type in each field label, like you have it in that most recent mock-up.
In addition to the voice-over scenario you mentioned earlier, I can imagine it being convenient if, for example, I'm on landscape mobile and the parent heading isn't in view.

Also, the device type names would be all singular or all plural. I know they're mock-ups. Just sayin 😃

@kjellr

This comment has been minimized.

Copy link
Contributor

kjellr commented Feb 18, 2019

Also, the device type names would be all singular or all plural. I know they're mock-ups. Just sayin 😃

Updated above.

@karmatosed karmatosed moved this from In progress to Tighten Up in Phase 2 Feb 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment