[4.0] Switcher have inversed "Yes/No" and are not clear

[Bakual]

Steps to reproduce the issue

Look at the options from a component, eg com_content options.
It uses a new design for the Yes/No; Show/Hide type of radio elements.

Expected result

• An intuitive way to select the parameters,
• A consistent behavior.

Actual result

• I had to first toggle a button a few times to figure out if it's activated or not because the toggle itself wasn't clear to me. Of course once I figured it out, it's clear again.
• The options are switched compared to J3. "Yes" is on the right side in J4 while it is left in J3.

Additional comments

There are a few things to consider here.

• First I really think the switcher itself needs to be improved. I think that's a task for UX experts. After reading a few articles found in Google they indicate that Apple does a good job with style here, but not so much with UX. Better would be to write both options ("Yes" and "No") on the respective side of the switcher so it's clear which side does what.
• Second we switched the order of the options in the past already, namely from J2.5 to J3. And now we switch it back again. I can tell you from personal experience that this wasn't a pleasant job to do for my extensions and it took several versions till it even was consistently done within core.
  For the upgrading user it is a bit confusing until he gets used to it again.
  While it seems to be standard to have "Yes" right on mobile phone OS, this doesn't mean we have to do the same. Much more important that on which side the "Yes" option is, is that it is clear where it is. Or to say it the other way: If the UX is clear, it doesn't matter at all if "Yes" right or left. We don't have to follow any so-called "soft" standard, we just have to get the UX right (which is the first point mentioned here).

Example Pictures

Joomla 2.5:

Joomla 3.x:

Joomla 4:

[Bakual]

On a sidenote, the small change in design to switch the option order makes it impossible to write an extension version which fits both with J3 and J4 design. Since the options will always be in the wrong order in one of the CMS version, no matter what you do.

[brianteeman]

I have raised the issue of the switcher many times to the developers of the template. I am not a fan at all.

Also see https://inclusive-components.design/toggle-button/

[C-Lodder]

I really don't see any issue here. There's nothing to "figure out". You have a switcher, you click, is displays the text. It's the same concept as iOS and Android, however they do not display any text, whereas we do.

I don't know why J3 displays "yes" on the left it's it's most certainly not the norm.

[brianteeman]

Whatever the norm and the rihts or wrongs of it It there is a very valid issue if this prevents an extension from working on J3 and J4

[dgrammatiko]

Switcher is optional, devs can keep their crappy things...
Core will utilise switcher

[brianteeman]

@dgt41 ok thats good then and oyu can ignore that issue

[dgrammatiko]

@C-Lodder I'm remembering correctly the approach here, right?

[C-Lodder]

@brianteeman - how does it "prevent" an extension from working on J3 and J4?

[brianteeman]

I still hate the switcher though and I hope you read the link so that the crappy switcher is accessible

[dgrammatiko]

@brianteeman we can improve things, but we have to start from somewhere. IOS and Android is a good foundation IMHO

[brianteeman]

for a phone yes ;)

[C-Lodder]

Explain why it's bad on devices other than phones/tablets. Remember we're even doing better by actually displaying text.

[dgrammatiko]

70% of web traffic is from phones, we should remember this metric!

[brianteeman]

@dgt41 traffic yes - development probably not

[brianteeman]

@C-Lodder if it is accessible then great but currently its not

[C-Lodder]

So it's not fact that "Yes" is displayed on the right. AFAIR, I switched the ordering or the yes/no round for ALL parameters, so that "yes" is on the right (green), unless it's not the recommended setting.

I'll can add in some basics for accessibility such as aria attributes etc (I believe colour contrast is already done but will have to double check). Other than that, the "UX" and a11y team will need to give some input.

a11y: @armenos @ylahav
UX: @nonexistant

[brianteeman]

@Bakual would know more about the issue of J3/J4 compatibility than me I was just taking him at his word on that

[Bakual]

There's nothing to "figure out". You have a switcher, you click, is displays the text. It's the same concept as iOS and Android, however they do not display any text, whereas we do.

I just can tell from my personal experience when I first saw the switcher, and it was not clear at all. I had to toggle the switcher several times to understand if the text shows the active state or if it is the action that will get triggered when I press it or if it is the state when the switcher is on the right side.
It didn't help of course that the switcher is inversed when coming from J3 (as I pointed out above).
The greyed out text doesn't help as well.
The main thing that helped was a showon behavior that was attached to the switcher I tried. 😄

So don't tell me there is no issue and nothing to figure out. I told you there is one. I may not be 20 anymore but I'm not stupid and I certainly don't think I will be the only one having initial issues with that switcher.

As for iOS and Android, that's actually a wrong comparision. We're not building a mobile phone app here. It's a web site. And while a huge amount of web browsing today comes from mobile phones, managing websites is a completely other statistic (desktops are preferred there).

I don't know why J3 displays "yes" on the left it's it's most certainly not the norm.

First of all there is no "norm". iOS and Android do it this way but that doesn't make it a "norm". As I wrote it's much more important to have a good UX, whatever position you choose.
It think it was a decision from the UX group at that time. To me it's more logical to have it left as well (We also say "Yes/No" or "Show/Hide" toggles for a reason). The only thing that wasn't logical was that you had to write the values in descending order in the XML.
What I find highly unlogical however is that we switch the order with each major release. We should stick to one.

how does it "prevent" an extension from working on J3 and J4?

It doesn't prevent an extension from working. But it prevents it from following the UX of both CMS versions. While you can easily add the classes "btn-group btn-group-yesno switcher" which will look nice both in J3 and J4, the order can't be adjusted to fit the CMS version. It will be either wrong in J3 or J4.

One drawback of that switcher obviously is that it will only work with boolean selects. You can't have them for "male/female" or for parameters with more than two options. Do we need to use a dropdown select in those cases? That would be a step backwards imho. But that's not the point here, just something to consider as well.

[C-Lodder]

I say the "norm" cause I had looked at a LOT of UI kits, both for mobile and web, and always say the green/active state on the right. I don't know of any system or UI kit that display it by default on the left.

I'm aware of the fields with more than 2 options. As it stands, the switcher can't be used for more than 2. In these cases I changed them to a select, but if someone has a different solution, PR's are welcome.

I just can tell from my personal experience when I first saw the switcher, and it was not clear at all. I had to toggle the switcher several times to understand if the text shows the active state or if it is the action that will get triggered when I press it or if it is the state when the switcher is on the right side.

If this is the case, what would you suggest changing about the switcher so that it's more clear? Cause An intuitive way to select the parameters does really tell me much.

[Bakual]

If you read a bit about switcher and UX, all answers indicate that the order doesn't matter at all.
They also indicate that the UX and accessibility of such switchers usually are bad compared to a simple checkbox or radio. Some even say it's unintuitive to click/tap a switcher because you rather would move it.
UX can be improved by doing something like this:
Yes [o ] No
Colors of course help, but one should not rely on them alone.

I'm aware of the fields with more than 2 options. As it stands, the switcher can't be used for more than 2. In these cases I changed them to a select, but if someone has a different solution, PR's are welcome.

Keep in mind that we currently have a solution for toggles with more than two options as well as for "male/female" type ones (where you can't set a default). It works fine in J3 and even looked consistent.
The more I think about those switchers, the less I think they are actually an improvement over the current solution. They are less flexible, less clear, less accessible. What exactly was the reason to implement them beside trying to mimic an iOS/Android feel (which is a stupid reason as we're not a mobile phone app)?

[Bakual]

Btw, just stumbled over what I think is a good a11y example for such a switcher (found on https://www.sbb.ch/en/home.html):

HTML Source looks like this:

There is a lot of hidden aria stuff the to make it accessible for screenreaders.

[dgrammatiko]

My 2c here, trying to fix the A11Y with a script that manipulates the DOM is the wrong (old way) approach, we should embrace custom elements here. Some examples:
https://www.webcomponents.org/element/arsnebula/nebula-switch/demo/demo/index.html
https://www.webcomponents.org/element/kcmr/liquid-switch
https://www.webcomponents.org/element/nuclei/material-toggle

[Bakual]

Where do you see the use of a script for a11y?
The "aria-describedby="togglebutton_hiddentext_departure" references the ID of the hidden span a bit further down which contains the description of the action. That was the part I meant.
Plus the labels for each possible states (Dep and Arr in this case).
For a11y purposes we probably need to add something similar.

In the end, I'm still not convinced why we should even use them. Looks like there are only limitations compared to the current solution with buttons.

[Bakual]

Closing since I did a PR to revert to the J3 buttons.
#15946