"Use switch instead of checkbox" must default to OFF

Thanks for expressing your opinion. I can't say I share your point of view however, and I think the switch is a much better fit as well as better for UX than the checkbox. Let's compare.

The checkbox can be construed in the same way as you've described as "confusing" in reference to the switch's colors. For example, when a module is unavailable to enable/disable, the checkbox version has the checkbox disabled. This is very similar to the switch in that we use a grey color instead of the usual red or green, and the switch is not switchable. Functionally a tie.

The implication of switching a switch on or off is the same as checking a checkbox. People on one hand can expect an immediate result of something whether using either visual indicator (a switch or a checkbox). It's not uncommon to see immediate AJAX response from checking a checkbox (or radios for that matter). Sometimes it's as simple as hiding/showing other page elements. Sometimes it's partially submitting a form (Aurora theme does this on it's settings page). The one thing the switch has going for it that the checkbox does not, is a visual state that implies the action is not complete. When toggling a switch to it's other state, it's color is yellow which signifies to the user it's neither green or red (on or off). Blocks admin page, and other draggable tables, do this with a yellow warning message, a yellow outlined row for the row that moved, and an asterisk that visually links the action to the message. For UX, the edge goes to the switch.

On the note of the ability to enable/disable modules immediately, I think this is quite doable. It would really be no different than submitting the form manually, but instead I foresee a modal popup shown in the event there are required modules that need to be enabled. Otherwise enabling the module could be relatively seamless. Much like emulating devices in Chrome's devtools, I'd also imagine a message be displayed (similar to the draggable tables message) when a module would be enabled/disabled stating to refresh the page to load any potential page features such as additional menu items or other features provided by the newly enabled module. My one reason for not taking a higher priority with this feature is the argument that it would be too slow to enable multiple modules. This is the one argument which is truly holding the feature back, not that the feature isn't feasible or doable. This functionality is neither pro switch or checkbox and can be accomplished for either.

So by my calculations, the switch edges out the checkbox specifically in UX.

I appreciate your perspective immensely, and I'm willing to continue the debate if you still feel strongly that the checkbox is better suited over the use of a switch.

Certainly, can leave this as active to help other eyes find it and contribute to the debate. ;)

I just updated this module from 7.x-1.8 to 7.x-2.0. After seeing the very confusing slide buttons, I immediately went to the issues queue to see if there was a patch to revert the controls to the familiar checkboxes. Thankfully, I found this thread which hinted that there was a settings page. I unchecked the "Use switch instead of checkbox" and all is well again.

Count me as one who finds the slide buttons very difficult to understand. The slide position and the positioning of the labeling are not intuitive. On a positive note, I did find the color coding to be useful.

Hello,

Could you please explain me in one phrase what is a GREY ON switch button?
I have (look attach picture) location_cck enabled with all requirement OK but still in gray and not in green.

Thank you

@fmantov The grayed out switch signifies it is locked in that position. This is the same has a disabled checkbox that is checked. Drupal locks modules ON if there are other modules enabled that depend on that module (these are listed in the "required by" listing for the module). On a similar note, Drupal locks modules OFF if they require modules that aren't available.

For your Location CCK module, it is locked in the ON position because it is enabled and there is another module enabled that requires Location CCK. Similarly, Location CCK requires the Location module which means you will find that module also locked in the ON position.

I agree that the switch is far less clear, and the default should be checkboxes.

Along with the UX issues outlined above, a disabled checkbox is clearly on or off because the check can be seen in either case. The disabled/locked switches (and this may depend on your admin theme) all look the same - they just have the switch in a different position.

Yes, the color does make it jump out more, but in my case with disabled switches, the color was not visible.

Also, scan your eye down a long list of checkboxes vs. a long list of switches with different positions and colors. I think it's hard to argue that switches are more clear. I think the “label as current status vs. label as switched status” issue is reason enough to default to checkboxes.

Why can't we explain the color coding at the top of the module page? This would be so easy and convenient.

Personally, I think that the switch is better than checkboxes, and should be the default, however, it seems clear that the fact that this module comes with a settings page with many useful options, is easily eluded.
IMO, that settings page should be made (more) available as a gray tab link along the top, beside the "uninstall" etc. other tabs.

I'm not a fan of the switches in 2.0 either. The checkboxes are much more concise and easy to understand than what 2.0 provides.

To be fair, however, it may just be the theming of the switch in this case.

Ok, so firstly, I did not even know that you could disable switches on the settings page for this module because I did not even know that such settings page exists. It would be nice to have some kind of indication that there are settings for this module.

Secondly, switches are not the most understood UX elements simply because they are not physical elements that every person saw in their life: same as electricity sockets, light switches (the most commonly used switches) differ from country-to-country. For me personally, the state of this switch is never clear as in Eastern European countries (where I'm originally from) the switches markings are written outside of the the switch elements, so you usually move the toggle _towards_ a side where the marking is specified. This is visually totally opposite to how the switches in this module show state.

With D10 now out going to putting all the focus on the 4.x version of this
module supporting D9 + D10.

Will keep an on the 7.x-2.x branch for reviews but no active work will
probably happen