I still disagree that a switcher is bad

@brianteeman There was at least a time when you thought otherwise: #15946 (comment) ?

I'm fully aware that it's a subjective thing in many regards.
I would love to hear arguments for the switcher. For example which issue it solves that can't be solved with a toggle button. Or in which way it is better UX than the toggle.

For me, it currently means that I have to adjust all XMLs in my extensions and especially also change the order of the options just to get the UI style of the J4 core. With no additional value.
In fact it looks worse in my eyes and is less intuitive (again, it is subjective). ?

yes that was before I spent so long using it

I definitely prefer the switcher UI (but I am an iPhone junkie). I also very much appreciate it's forced us to create cleaner labels (by having less text in the buttons and having them as simple yes/no).

I am aware that forcing people to reorder their XML files is a pain though and is something we could see if we can improve if possible. Given switcher is now fully css styled though now rather than a web component we could probably improve that with CSS classes though

I also very much appreciate it's forced us to create cleaner labels (by having less text in the buttons and having them as simple yes/no).

Hmm, it doesn't force us. In fact you could have longer texts now and it doesn't look that weird as with buttons
Buttons:

Switcher:

But I see that example as something we try to avoid - and by switcher styling it a bit awkwardly - it's improving the overall UX

But I see that example as something we try to avoid

Of course we try to avoid that. My point is that it isn't the switcher forcing that. In contrary, it would allow longer texts than button groups (where the text has to fit into the button).

from a ui perspective I find it much easier to scan down a list of options using the switcher approach and get the settings. I dont need to think what the funny shading indicates. I dont need to "filter" out the extra text. I just read - Option - yes

@Bakual

For me, it currently means that I have to adjust all XMLs in my extensions and especially also change the order of the options just to get the UI style of the J4 core. With no additional value.

No, you don't. You're quite within your right to use whatever you want in your extensions. Switchers are optional classes, not mandatory. You can use native radio/checkboxes or the btn-group btn-group-yesno in your extension XML.

No, you don't. You're quite within your right to use whatever you want in your extensions. Switchers are optional classes, not mandatory. You can use native radio/checkboxes or the btn-group btn-group-yesno in your extension XML.

Not when you want to deliver an uniform UX across extensions. I personally hate each extension that uses its own style. So no, that's no option for me.

Just update Isis for 4.0 and all the debate about all the "terrible" changes in the UI can go away ?

That's a very good argument you bring there....

Some universal rules about Toogle/Switch?
https://www.nngroup.com/articles/toggle-switch-guidelines/

You cannot compare an OS or Phone UX to web. They are all very different.
On an OS or Phone, there is no "save" button for settings. Even checkbox selections are saved on the fly.

If articles keep being thrown in to the conversation about when Switchers should actually be used, without any regard between the differences between web and phones settings, then I expect checkboxes, ranges, dropdowns and others to be saved on the fly too.

You cannot compare an OS or Phone UX to web. They are all very different.
On an OS or Phone, there is no "save" button for settings. Even checkbox selections are saved on the fly.

plus 10000000

I expect checkboxes, ranges, dropdowns and others to be saved on the fly too.

Usability (different thing) and UI are not different if you have to confirm a choice or not. At UI level most of things that you see in the worldwide approved design principles, are good.
Or are you new prophets of a new design trend that will change the world?

You need to try some more admin UI from others apps...

@C-Lodder The articles @simbus82 and me referenced are explicit about web applications, not phones.
Even in my PR description I state the same as you: Don't take the UI of phones as guidance as they work completely different (most importantely as you said they save instantely). Yet we have the switchers which (I believe) are inspired by mobile phones.

What is written in the articles and what I am saying is that "Switchers" should apply instantely or they are the wrong UI element.
Of course, one can also save checkboxes instantely, nobody said something different. You can also save listboxes instantely. All fine. But you shall not have Switchers that DON'T apply immediately. That's the point.

I meant that the UI is not different if i need to save or not... for example a "apply/save button" can be enabled only if a change was made.
But the article that i have referenced is because i want to avoid errors like this

The most important thing, switch or group of buttons, is that you immediately understand (even for a color blind) what is the current state and what can be the alternate state, but without creating all different widths or an indecent visual impact.

Another example: all here is wrong.

"Questions" just have to accept only yes/no answer, not some yes/no, some hide/show.
Why not to change questions?

• Show category [yes|no]
• Link category [yes|no]
• Show parent [yes|no]

Using uniformity and then choosing a default for the question (ex."Show this or that")

The most important thing, switch or group of buttons, is that you immediately understand

That is why I favour the switcher as I only see the active state

@simbus82 @Bakual

What is written in the articles and what I am saying is that "Switchers" should apply instantely or they are the wrong UI element.

Do those articles take into consideration things like request caps on shared hosting? Probably not.
What if you're on shared hosting with a capped request limit but want users to be able to use a familiar UI element?

I would argue that those articles are a little under two years old. Do you have any more up to date evidence? What about Twitter and Slack? They use checkboxes that save on the fly. Is that a new 2020 UX standard? Should Joomla be doing the same with checkboxes in 2020 too?

I would then also argue that buttons are supposed to perform actions...such as the "Save" button. You click it, it does something. These elements that you're making look like buttons but do not actually perform any action themselves. Any comment on this?

What about the fact you're adding more text to pages that already have enough options? It's becoming a busier view...there's more text to scan on the page. Any comments on this?

That is why I favour the switcher as I only see the active state

Unfortunately it's not clear that it shows the active state. You first have to work with it and click it a few times till you understand that. It's not intuitive.

What about Twitter and Slack? They use checkboxes that save on the fly.

Checkboxes are regular HTML elements. Switchers are not. So using checkboxes in whatever ways you want is absolutely fine. Switchers on the other hand are custom elements and come from the smartphone era.

I would then also argue that buttons are supposed to perform actions...such as the "Save" button. You click it, it does something. These elements that you're making look like buttons but do not actually perform any action themselves. Any comment on this?

I'd say they are at least intuitive and familiar.

What about the fact you're adding more text to pages that already have enough options? It's becoming a busier view...there's more text to scan on the page. Any comments on this?

I've actually never had an issue with that, and find the switcher harder to scan. It's subjective.

I'd say they are at least intuitive and familiar.

Familiar to who?

I would happily accept that native checkboxes and radio are familiar.

Familiar to who?

At least to all Joomla people and all that are used to Bootstrap templates ?

I hoped to get arguments why the switcher is better UI than the buttons. Only got a single subjective argument as far as I see.
But I have no interest in a heated fighting just for some design stuff
So I'm closing this RFC.

Lol, there's nothing heated about this. We're having a poilte, healthy discussion.

I'm coming back with counter questions because I believe you want to remove them for the following reasons and the following reasons alone:

1. You don't want to update your extension XML.
2. You're accustomed to the Joomla 3 radio toggles which are based on Bootstrap styling (which by the way, has not proven to be "good" UX).

You want my actual opinions on why I'd go with a switcher over a radio toggle?
Because I personally find them:

• Nicer to look at
• Simple
• Less clutter
• Better UX than buttons, which should perform an action

That said, UX differs per site. Just because something works somewhere, doesn't mean it'll work elsewhere. With that in mind, you're actually the only person who doesn't like the switcher. I haven't seen any complaints from other alpha testers about them.