Jetpack: Settings: Child toggles should activate parent toggles

[jeffgolenski]

Within the new settings UI I discovered a missing detail that could potentially cause some user confusion / frustration.

As seen in the gif above, when a user clicks/taps a parent toggle option, the child toggles then gain the ability to be toggled. In this case, you can't toggle the options for related posts ("show a visually striking layout") until the parent option for related posts is turned on ("show related posts")

But if a parent option is turned off, the child option toggles cannot be toggled on or off, but they still display.

Since there is an incredible amount of toggles within this new settings UI, and very little visual differentiation between parent option and child option toggles, I foresee a lot of users attempting to click on the child option toggles and them getting frustrated when nothing happens.

If a user clicks "display a visually striking layout" for the related posts child option while the related post parent option is inactive, it should activate it. Obviously, the user wants to use that feature, and we can save them an extra click or tap by doing it for them.

cc @MichaelArestad

[jeffgolenski]

Either this ^^ or hiding the child options until the parent options are enabled I think is the way to go. I just feel like there's now an overwhelming amount of toggles now and placing a more defined actionable hierarchy may be the way to go.

[dereksmart]

Hm. Maybe if this is actually a concern, then we should just hide the children options instead when the parent is disabled.

The point of having different styles for disabled toggles is to communicate that they cannot be interacted with.

Another alternative would be to not make them disabled ever, even when the parent is inactive. Like this:

either way I don't think we should allow interacting with disabled toggles.

[MichaelArestad]

Either this ^^ or hiding the child options until the parent options are enabled I think is the way to go.

No hiding. We started with that and it wasn't as good.

The point of having different styles for inactive toggles is to communicate that they cannot be interacted with.

That's true, but it's more of a shortcut to enable in this case. They would enable the module and themself at the same time. I think calypso used to do this, but it may have been reverted. @oskosk or @tyxla might know.

[tyxla]

No hiding. We started with that and it wasn't as good.

I confirm - we did try to hide settings for Related Posts (https://github.com/Automattic/wp-calypso/pull/10423), it didn't work well, and we got back to disabling fields instead of hiding (https://github.com/Automattic/wp-calypso/pull/10925).

That's true, but it's more of a shortcut to enable in this case. They would enable the module and themself at the same time. I think calypso used to do this, but it may have been reverted.

I don't recall that we've been doing that in Calypso so far.

In any case I find this behavior to be counter-intuitive, because if you can click on a disabled toggle and this triggers something, then why is it disabled in the first place? I've never seen that done in any interface I've used so far. So I'd prefer keeping disabled toggles totally inactive, predictive and intuitive. Just my two cents.

[rickybanister]

I tend to agree with @tyxla here—we are showing the sub-toggles as a kind of courtesy to users, helping preview the sub options.

@jeffgolenski's proposal makes sense for a simple feature with one or two sub-toggles, but for a feature like spell-check with dozens of sub-toggles it is likely better if the user explicitly opts into the primary parent toggle before interacting with the sub-toggles.

This is already marked 'non-urgent' but I wouldn't mind closing this out for now to let us focus on shipping settings.

[MichaelArestad]

I'm okay with closing this out for now. I don't think it's a big enough improvement to mess with and, as @rickybanister pointed out, could be messy.