Que faites-vous lorsque vous avez trop de choix dans un ensemble de champs de case à cocher?
J'ai une interface pour gérer les rôles d'un utilisateur dans une interface pour gérer les comptes dans une application Web.
Les rôles sont essentiellement des rôles dans le contexte Contrôle d'accès basé sur les rôles - (RBAC) .
Caractéristiques:
- Les utilisateurs peuvent avoir plusieurs rôles, voire aucun.
- Tous les utilisateurs, qu'ils aient ou non des rôles, auront toujours un rôle "membre" par défaut. L'appartenance à ce rôle de "membre" ne peut pas être supprimée et "colle" toujours à chaque compte d'utilisateur.
Compte tenu de cela, il semble qu'un groupe de cases à cocher serait le contrôle le plus approprié:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Cependant, je n'ai que 6 rôles + le rôle de membre par défaut là-dedans et l'ensemble de champs semble déjà un peu long. Obtenez jusqu'à 12 à 14 rôles et la chose deviendra tout à fait inutilisable.
Y a-t-il des alternatives ou d'autres contrôles que je peux utiliser au lieu d'avoir un ensemble de champs très long? Dans la maquette ci-dessus, l'ensemble de champs serait presque impossible à utiliser s'il y a 100 rôles dans le système.
Les exigences sont les suivantes:
- Je dois pouvoir afficher le nom et la description du rôle.
- Les utilisateurs peuvent avoir plusieurs rôles.
- L'ajout ou la suppression d'un rôle pour un utilisateur ne devrait pas prendre beaucoup d'efforts.
- L'utilisateur doit pouvoir voir TOUS les rôles. Bien que la fonctionnalité "tags" de StackExchange fonctionne bien, dans ce cas, il peut être difficile de "deviner" le nom d'un rôle pour démarrer le processus de saisie semi-automatique.
Quelques précisions concernant les groupes:
Actuellement, le processus de création d'un rôle est sans friction: l'utilisateur donne simplement au rôle un nom, une description facultative et définit les autorisations en cochant certaines cases.
Il n'y a aucun sens des départements, ou des groupes ou quelque chose comme ça. Les rôles créés ont tendance à ne pas être spécifiques à un département ou à un groupe et ont tendance à être assez généraux: 2 personnes travaillant dans des départements différents pourraient avoir le même rôle.
Dans ces circonstances, existe-t-il d'autres façons de procéder au regroupement? Ou devrions-nous simplement présenter les rôles sous forme de liste triée par ordre alphabétique?
Pour moi, il y a trois choses que je ferais pour simplifier cette conception.
1) Je pense que vous devriez supprimer le rôle Member de la liste des rôles . Les utilisateurs ne peuvent pas modifier cela, il ne doit donc pas faire partie du groupe. Au lieu de cela, il peut être répertorié avec tous les autres rôles sélectionnés ailleurs (éventuellement avec un titre descriptif, par exemple un rôle par défaut, ou un rôle de base ou certains autres). Vous pourriez même vous demander si vous devez afficher ce rôle. Oui, le système doit le savoir, mais doit-il faire partie du modèle mental des utilisateurs?
2) Les descriptions doivent-elles être présentes à tout moment ? Une fois que les gens savent ce qu'est un rôle, ils n'ont vraiment plus besoin des descriptions. Ne pourraient-ils pas simplement apparaître dans une fenêtre contextuelle au survol/survol ou cliquer. Alternativement, ils pourraient apparaître dans une zone de texte adjacente mais ce n'est pas aussi connecté, donc probablement une solution moins idéale. La suppression des descriptions vous permettrait d'économiser beaucoup d'espace et vous permettrait également de regrouper les cases à cocher si la liste s'allonge.
3) J'aime bien l'idée d'ajouter des icônes/illustrations à la liste ... rendrait certainement les rôles plus mémorables pour les utilisateurs au fil du temps.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Vous pouvez également autoriser les utilisateurs à supprimer les rôles de la fenêtre supérieure. Comme vous pouvez supprimer des balises dans de nombreuses interfaces utilisateur ces jours-ci.
[~ # ~] mise à jour [~ # ~]
Le regroupement tel que suggéré par la réponse de dnbrv est également une bonne façon de procéder. Cependant, je préférerais un style de regroupement plat (plutôt que des onglets) - si la liste devient trop longue, vous pouvez utiliser un défilement.
La couleur est utile pour souligner les groupes (peut être appliquée aux balises dans la section supérieure).
Vous pouvez autoriser les utilisateurs à sélectionner leurs propres icônes via des bibliothèques d'icônes. Par exemple, Facebook en a un comme celui-ci:
Balsamiq vous permet également de choisir des icônes dans une bibliothèque, puis de sélectionner la couleur. Il vous permet également de sélectionner une taille qui est souvent utile pour l'accentuation: 
Solution de base.
Lignes directrices pour la conception d'une interface graphique à l'échelle de l'entreprise recommande d'utiliser une liste de sélection dans de telles circonstances. Vous pouvez afficher 5-6 rôles et mettre une barre de défilement pour permettre de visualiser le reste. De cette façon, l'utilisateur peut comprendre le contenu de la liste, puis utiliser la barre de défilement pour les voir tous et choisir le nécessaire. Cela vous donne également de la flexibilité car il est plus facile d'ajouter/supprimer des rôles dans une liste que les cases à cocher d'un panneau.
Pour le rendre encore meilleur.
La liste présente des inconvénients de ne pas pouvoir voir assez facilement les éléments déjà sélectionnés. De plus, la sélection est une opération un peu difficile: l'utilisateur peut ne pas être conscient du bouton à maintenir pour sélectionner plusieurs éléments. La solution serait d'avoir 2 listes. L'un montre les rôles disponibles, un autre les rôles sélectionnés. L'utilisateur peut soit glisser-déposer, soit utiliser des boutons pour fonctionner. Voici à quoi ça ressemble:
Ensuite, si l'utilisateur sélectionne les rôles et appuie sur ajouter, cela ressemble à ceci:
Exemple du monde réel.
Cette solution est en fait assez souvent utilisée dans les applications de bureau. Voici une capture d'écran de NetBeans, qui est un IDE populaire:
La capture d'écran présente également des éléments désactivés pour indiquer clairement à l'utilisateur que certains éléments ne peuvent pas être ajoutés/supprimés. Vous pouvez utiliser le même concept pour votre rôle "Membre". Les boutons reflètent également l'état de sélection. Par exemple, si aucun élément de la liste Tables disponibles n'est sélectionné, le bouton Ajouter est désactivé, etc. Vous pouvez utiliser la zone de texte en bas pour afficher la description du rôle, comme vous l'avez mentionné.
Ma solution est plus une combinaison des réponses précédentes car elles ont toutes de bons points mais aucune ne la cloue sur la tête.
Les cases à cocher ne sont pas le problème. Le problème réside dans le nombre de choix, et il est facilement résolu avec la taxonomie. Vous devez organiser les rôles en groupes par département, fonction de travail, uniformes ou tout autre élément ayant du sens pour la personne qui attribue les rôles afin de trouver facilement ce qui est nécessaire.
Une fois les groupes finalisés, convertissez-les simplement en onglets de cases à cocher. Vous devez également afficher les rôles déjà attribués (avec un contrôle "supprimer"/"annuler l'attribution") au-dessus de la liste pour faciliter la visualisation de l'état. Lorsque la souris survole un rôle dans la liste affectée, une info-bulle doit apparaître avec au moins le nom du groupe, et s'il y a suffisamment d'espace également avec la description du rôle. Lorsque la souris survole un rôle dans la liste de tous les rôles, une info-bulle doit apparaître avec la description de ce rôle.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Je considérerais trois approches, si la liste est susceptible de s'étendre à plus de 100 entrées.
Listbox avec cases à cocher. Cela couvrirait un nombre assez important de plus que les cases à cocher standard.
Regrouper les rôles, de sorte que la sélection de "DBO", par exemple, sélectionnerait automatiquement les rôles qui en font partie.
Une expansion à ce sujet, mais définissez un ensemble de types de rôles et autorisez la sélection à partir de ceux-ci (uniquement). Permet également de définir de nouveaux types de rôles, en utilisant probablement les 2 listes de @Ganga. Prolongez cela en permettant à l'utilisateur de dire "le même rôle/s que xxx".
Vous devez considérer comment les gens vont utiliser cela. S'il y a 100 rôles, très peu de gens voudront avoir à les sélectionner tous. Cela n'a pas de sens - la plupart du temps, ils veulent définir quelqu'un comme xxx ou comme aaaa. Permettez-leur donc de faire les choses de cette manière, tout en leur donnant la fonctionnalité ou en autorisant toute combinaison de rôles.
Et au niveau de la mise en œuvre, aucune de ces options ne fait de différence. Dans tous les cas, il vous suffit d'attribuer des rôles aux utilisateurs. Il s'agit simplement de la façon dont ceux-ci sont sélectionnés.
J'ai toujours eu du succès avec les combos. Fondamentalement, vous obtenez une liste déroulante où les éléments dans la liste déroulante ont des cases à cocher.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Chaque fois que le menu déroulant est réduit, vous pouvez voir ce que vous avez sélectionné, et chaque fois qu'il est développé, vous pouvez le saisir pour rechercher rapidement l'une des options vous devez sélectionner. Et cela ne prend pas non plus beaucoup de place.
EDIT a modifié la description du comportement élargie afin qu'elle puisse mieux convenir à une très grande liste.
Vous pouvez afficher les rôles de base, tels que membre, etc., puis disposer d'un bouton "plus" qui affiche le reste. Une interface à onglets serait également utile