Je travaille sur un système destiné à des utilisateurs plutôt techniques - ingénieurs, etc. Le système se compose de plusieurs fenêtres, chacune offrant à l'utilisateur la possibilité de configurer (créer/éditer) un objet dans le système. Chaque objet possède de nombreux attributs, répartis sur différents panneaux selon une certaine pertinence de sous-objet. Chaque panneau se compose d'une liste d'attributs dont certains sont de type Activer/Désactiver. Les derniers représentent généralement l'état activé/désactivé d'un attribut dans l'objet.
Ma question est: pour ces options Activer/Désactiver, quelle est la méthode préférée: Une seule case à cocher ou deux boutons radio? Ou peut-être, un mélange d'entre eux dépend de l'attribut?
Quelques exemples:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
J'irais avec les règles des normes GUI et les normes Web officielles du W3C:
Les boutons radio sont utilisés lorsqu'il existe une liste de deux options ou plus qui s'excluent mutuellement et que l'utilisateur doit sélectionner exactement un choix. En d'autres termes, cliquer sur un bouton radio non sélectionné désélectionnera tout autre bouton précédemment sélectionné dans la liste.
Les cases à cocher sont utilisées lorsqu'il existe des listes d'options et que l'utilisateur peut sélectionner n'importe quel nombre de choix, y compris zéro, une ou plusieurs. En d'autres termes, chaque case à cocher est indépendante de toutes les autres cases à cocher de la liste, donc cocher une case ne décoche pas les autres.
Une case à cocher autonome est utilisée pour une seule option que l'utilisateur peut activer ou désactiver.
De Nielsen Norman Group Cases à cocher vs boutons radio
Les boutons radio ajoutent une charge cognitive à l'utilisateur et encombrent l'interface sans apporter de clarté supplémentaire.
Vous pouvez augmenter la clarté et réduire davantage l'encombrement avec cette approche:
Enable:
[] Administrative state
[] Graceful restart
[] Default route
[] Multiple paths
Le groupe de cases à cocher implique une option plutôt que des états par défaut. Ce ne serait pas la bonne méthode à utiliser si vous voulez montrer à l'utilisateur quels sont les états par défaut. Le premier groupe utilisant des boutons radio est une meilleure utilisation. Dans les pages de paramètres iOS, ils utilisent des interrupteurs à bascule pour indiquer si quelque chose est activé ou désactivé. Cela semble être la meilleure façon de montrer ce cas d'utilisation que vous décrivez.
Pour simplifier et reformuler la réponse de Samuel:
Utilisez 1 case à cocher si le choix est n sur deux options. Ou plutôt, un choix binaire.
Utilisez les boutons radio si le choix est n sur X options.
Utilisez les cases à cocher X si le choix est Y sur X options. Il ne s'agit en fait pas d'une seule option avec plusieurs options de sélection, mais d'une série d'options que vous pouvez sélectionner individuellement.
Il y a, comme toujours, une exception. Ou plutôt une complication. Si vous avez une option sur deux, vous pouvez toujours utiliser des boutons radio. Si l'option est "accompagnement de frites", il est logique d'avoir une case à cocher. Soit vous le voulez, soit vous ne voulez pas de côté. Quelque chose ou rien.
Mais si l'option est "salade d'accompagnement ou frites" ... laquelle signifie la case? Un ensemble de deux boutons radio rend beaucoup plus clair celui qui est sélectionné. Comme avantage supplémentaire, il offre de meilleures options pour une expansion future, lorsque le restaurant souhaite avoir du pain frit, de la salade et de l'ail comme accompagnements.
Mais dans vos exemples, toutes les options concernent l'activation ou la désactivation de fonctions. Allez donc avec des cases à cocher.