Case à cocher vs bascule
Il y a un débat constant sur la case à cocher vs la bascule. 
Personnellement, en tant que propriétaire d'iPhone et de Mac, je suis toujours très confus à chaque fois que je vois la bascule. Je me demande souvent: "Le" on "est à gauche, cela signifie-t-il que je dois faire glisser le gris clair de droite à gauche pour l'activer?" J'ai finalement découvert que la réponse était non. Pourtant, je dois encore penser à l'exercice chaque fois que je vois la bascule.
Mis à part les sentiments personnels, quels sont les bons arguments pour utiliser les cases à cocher vs les bascules?
Cela a été discuté en profondeur dans de nombreuses autres questions connexes (voir le volet droit sur cette page). Je serai donc bref.
Les interrupteurs à bascule sont anti-utilisabilité
Malgré leur popularité relative (par exemple, Apple utilisez-les comme contrôle d'interface standard), les commutateurs à bascule ont une inhérente ambiguïté de l'état-action; c'est-à-dire qu'il n'est pas clair si le label ('on' par exemple) est l'état actuel, ou l'action.
Un autre problème avec ceux-ci est que le profane peut facilement conclure que pour changer l'état, il faut faire glisser la poignée (comme dans le monde réel) plutôt que de cliquer n'importe où sur l'ensemble du contrôle.
Forme ludique
Le style des commutateurs à bascule dans votre exemple (qui n'ont qu'une seule étiquette à l'intérieur du commutateur) est en quelque sorte une tentative ridicule de prendre quelque chose du monde réel et créer une métaphore d'interface. Ainsi, ce type de commutateurs à bascule viole également la directive form-follow-function.
Dans le monde réel, les commutateurs sont beaucoup plus basiques que ceux de votre exemple, obligeant les fabricants à fournir des étiquettes et des lignes de trace pour tous les états possibles. Comme dans cet interrupteur du monde réel:
Les cases à cocher sont plus faciles à interpréter
Il existe différentes façons d'améliorer la convivialité de ces commutateurs, et il faut se rappeler qu'ils sont à la fois assez populaires et ne nécessitent que quelques itérations d'apprentissage avant que la plupart des utilisateurs ne l'obtiennent. Mais d'un point de vue cognitif, une case à cocher est beaucoup plus facile (et plus rapide) à interpréter qu'un interrupteur à bascule.
Le contexte pourrait être considéré dans ce débat plutôt que de se concentrer uniquement sur le contrôle lui-même.
Le contexte peut être une longue enquête riche en données destinée à être remplie avec un clavier, ou des paramètres utilisateur sur une application destinée aux appareils mobiles ou à écran tactile.
Chaque situation peut exiger quelque chose de différent pour permettre la meilleure expérience utilisateur et les meilleurs résultats.
Les méthodes d'interaction et les commentaires des utilisateurs peuvent également affecter l'utilisabilité des commandes telles que les interrupteurs à bascule. Par exemple, les paramètres basculent sur iOS7/iPhone;
[~ # ~] désactivé [~ # ~] ressemble à ceci
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Et [~ # ~] sur [~ # ~] ressemble à ceci;
L'interaction aide ici en fournissant des commentaires utilisateur en temps réel lors de l'utilisation de la commande à bascule (le commutateur devient vert et toutes les informations apparaissent).
Je ne connais pas la réponse, mais je sais que j'essaierais toujours de considérer le contexte et l'interaction avant de choisir d'utiliser une alternative à l'humble case à cocher!
L'implémentation du commutateur que vous avez affiché n'est pas correcte. Reportez-vous à l'image ci-jointe . 
La manière IOS de dire oui et non aussi est un peu floue pour moi.
J'utilise des cases à cocher lorsque j'ai une situation OUI/NON ou D'ACCORD/DÉSACCORD comme celle-ci:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Pour une bascule, j'utilise une sélection entre deux situations de poids égal telles que: ASCENDANT/DESCENDANT; ou FEMME/HOMME
J'essaie de régler ce problème exact en ce moment. Pour moi, il s'agit de ce que la sélection de l'option "signifie". Par exemple, je développe actuellement des interfaces de contrôle; l'un d'eux sélectionne quels "appareils" seront utilisés selon un certain calendrier, avec des sous-contrôles pour combien de temps ils seront utilisés et quelques autres choses, une autre interface de contrôle sélectionne sur quel (s) intervalle (s) le calendrier s'exécutera. Sous le capot, ce sont deux éléments de case à cocher, mais pour la sélection de l'appareil, j'utilise des bascules "on/off" (ou un bouton qui change le texte/l'apparence au clic pour mobile) et pour la sélection d'intervalle, j'utilise une case à cocher standard. La sélection d'appareil implique un "engagement" de l'appareil (il est littéralement allumé ou éteint), mais la sélection d'intervalle n'est que cela, une sélection. Cela a du sens pour moi, et je pense que c'est clair pour les utilisateurs ...
Dans l'ensemble, les cases à cocher sont préférables, mais nous ne devons pas perdre de vue les moments où elles sont utiles. Parfois, les utilisateurs - en particulier dans les scénarios experts, ont simplement besoin d'un indicateur DONE/NOT DONE ou APPROVE/NOT APPROVE.
J'inclus un graphique ci-dessous (j'ai supprimé toutes les informations incriminantes et sensibles :)
Ne vous occupez pas du "cadenas", de "l'enveloppe" et du cercle rouge. Tout cela a à voir avec d'autres actions.