@JFernandez-WMF @KStoller-WMF Do any of you have any thoughts on how boolean controls should be displayed by default (ie. not necessarily in our context)? Should we be using checkboxes with a question next to them (so no bold label at top, and instead of the x, a question)? Should we have the question at top, and then instead of x, say Disabled (or Enabled)? Should we use the radio buttons approach for everyone? Something else?

@Sgs Please note this task, as it somehow overlaps with the scope of T358663.

Thanks for creating this task to help escalate this decision, @Urbanecm_WMF!

I'm assigning this to @JFernandez-WMF as I think this is a UI / design question that she might need to consult with other designers on.

I know that we are attempting to move towards on/off language rather than enabled/disabled.
https://doc.wikimedia.org/codex/latest/style-guide/writing-for-copy.html#this-is-for-everyone

Radio buttons or toggles are better than a checkbox with an "x". This "x" will certainly be one of the first obvious feedback we will get.

If we go with radio buttons, the yes/no choice should be privileged, as it simplifies a lot the translations.

In T362044#9700836, @Trizek-WMF wrote:

or toggles

The toggle description says:

Use the ToggleSwitch component only where an instant change in the user-interface based on their assigned action is intended.

Community Configuration edits site configuration, which affects people after it’s saved, not immediately, so it’s not what ToggleSwitch is intended for. What remains is:

• A checkbox with a readable label (e.g. put the checkbox in front of Should users be automatically eligible for mentorship?, in the same line, rather than below it).
• Two radio buttons. A pre-made yes/no choice (translated only once) is a good idea.

Thank you all for bringing this to my attention, and thank you @Tacsipacsi for chiming in. That is correct, ToggleSwitch is meant for an immediate response (it saves changes in real-time). This wouldn't accommodate our use case, since we have a 'Save' button.

I say let's use radio buttons — thoughts?

This happens, because we have communityconfiguration-mentorship-gementorshipautomaticeligibility-control-label and communityconfiguration-mentorship-gementorshipenabled-control-label set to x. This was done, because without doing so, the form looks even worse:

Looking back, maybe this was not a good decision and it's causing confusion. The community configuration boolean control as it is now holds three message keys, all of them optional:

• communityconfiguration-PROVIDER_NAME-PROPERTY_NAME-label
• communityconfiguration-PROVIDER_NAME-PROPERTY_NAME-control-label
• communityconfiguration-PROVIDER_NAME-PROPERTY_NAME-help-text

This setup makes it trivial to display a checkbox with inlined text by only setting the "-control-label" message and leaving the rest empty:

I think this approach should have preceded the "x" label decision, which as far as I remember was just a shortcut to prevent an ugly form.

The mess here comes from the historical treatment of booleans in the GrowthExperiments extension Special:EditGrowthConfig form. This form has been crafted over years and the code backing it has resulted in tons of special casing which are not appropriate for a generic form generator (see source). Across the multiple special casing that form has there are two different controls used to capture booleans: yes/no radio buttons and checkboxes. Both are appropriate but present some problems when trying to make them generic. See:

Two radio buttons. A pre-made yes/no choice (translated only once) is a good idea.

This can be challenging. The radio buttons approach requires extra context information for some answers, eg: Yes, allow users meeting all eligibility criteria below to enroll as mentors.. We could support the extra information as help text but it seems it could result in a long explanation for each option, so not an ideal UX. Another problem with the radio button approach is that it forces writing the label in a question-like format, which might be ok for some cases but not sure it is a good fit for all booleans. Take in account a use case similar to the "Gadgets" section in Special:Preferences.

In the checkbox approach the problem is minor, maybe even not a problem but let me elaborate. When the user faces the "Copyedit" checkbox, they should read "Disabled" as an assertion and then the social convention is that marking the checkbox and saving will make the system comply to that assertion. In this case the assertion "Disabled" is kind of a negative clause (Not enabled). People with dyslexia can struggle to solve this puzzle. In general, I'd say a form guideline for checkboxes should be to propose a positive clause by the side of the control. It should be trivial to turn a "opt-out" checkbox like this one into a marked checkbox with a positive clause, then the mark and the text match in terms of semantics.

In T362044#9696485, @Urbanecm_WMF wrote:

@Sgs Please note this task, as it somehow overlaps with the scope of T358663.

It is somehow related because I used the yes/no boolean control as the first consumer of the feature T358663: Allow consumers to customize the default editor UI representation for an option. However I find that feature interesting, aside of the decision we make here. It would support known desired use cases such as the one mentioned in T356857: Allow providers to add a custom field (which is probably a dup btw).

tl;dr

I say let's use radio buttons — thoughts?

I think we should support both, but the checkbox should remain as the default. I think we want to update copy texts to better match the default checkbox control and drop the yes/no radio button from GrowthExperiments forms as soon as we can. The reason why we did support this particular case was probably a wrong assumption, which consisted on setting the UI expectation to be 100% mimic Special:EditGrowthConfig.

In T362044#9713353, @Sgs wrote:

In the checkbox approach the problem is minor, maybe even not a problem but let me elaborate. When the user faces the "Copyedit" checkbox, they should read "Disabled" as an assertion and then the social convention is that marking the checkbox and saving will make the system comply to that assertion. In this case the assertion "Disabled" is kind of a negative clause (Not enabled). People with dyslexia can struggle to solve this puzzle. In general, I'd say a form guideline for checkboxes should be to propose a positive clause by the side of the control. It should be trivial to turn a "opt-out" checkbox like this one into a marked checkbox with a positive clause, then the mark and the text match in terms of semantics.

Agree having the default as 'negative' may be confusing. Can we use 'Turned on' as the default?

I think we should support both, but the checkbox should remain as the default. I think we want to update copy texts to better match the default checkbox control and drop the yes/no radio button from GrowthExperiments forms as soon as we can.

Got it, that makes sense. Should we accommodate all most? radio buttons to checkboxes? I'm wondering what would happen when the question doesn't imply Yes/No answers. For example:

Using a checkbox here isn't really cohesive IMO. Since I am guessing this example only allows one selection and radio buttons are best for that kind of case.

In T362044#9714456, @JFernandez-WMF wrote:

Agree having the default as 'negative' may be confusing. Can we use 'Turned on' as the default?

Yes, can we capture this somewhere in the form guidelines?

Got it, that makes sense. Should we accommodate all most? radio buttons to checkboxes?

Right, we should update copy texts accordingly. So far, the mentorship ones, should I create separate task for this?

I'm wondering what would happen when the question doesn't imply Yes/No answers. For example:

Using a checkbox here isn't really cohesive IMO. Since I am guessing this example only allows one selection and radio buttons are best for that kind of case.

Indeed, after discussing this problem with engineers we decided that we will represent this selection as an enumeration of strings rather than a boolean, see T362685.

In T362044#9719138, @Sgs wrote:

Yes, can we capture this somewhere in the form guidelines?

Sure, I'll add it.

Right, we should update copy texts accordingly. So far, the mentorship ones, should I create separate task for this?

I have created T362905: Community Configuration: update copy to accommodate radio buttons to checkboxes in Special:CommunityConfiguration/Mentorship for this matter and I will update the task description with the suggested copy. Feel free to make any changes to the task you feel are necessary :)

Can we consider this task resolved?