Comment puis-je améliorer l'intuitivité / UX de la structure arborescente représentée?
Contexte
Dans notre application, nous avons une arborescence client/utilisateur. Selon le rôle signé dans un niveau de l'arborescence sera affiché, où un super utilisateur (SYSTEM) voit tout et un Le client (par exemple Ford) se voit lui-même et tous les branchements/nœuds sous lui.
Un nœud client a deux succursales, une pour ses clients et une pour ses utilisateurs. L'image ci-dessous le décrit plus en détail:
Comme vous le voyez, tous les nœuds clients ont la même structure, il a un nœud Clients et Utilisateurs nœud. Il existe également une fonction de recherche/filtrage qui étend les branches au nœud et sélectionne le nœud recherché. Lorsqu'un nœud est sélectionné, une feuille à droite de l'arborescence affichera un tableau du contenu du nœud et fournira des actions utilisateur telles que "Créer un nouveau client" ou "Créer un nouvel utilisateur" .
Problème
Le problème est cependant qu'il n'y a plus de bonne représentation des nœuds dans l'arborescence qui sont des clients et des utilisateurs, et également des nœuds qui sont simplement des nœuds de branchement/catégorie, tels que les utilisateurs et Clients nœuds. La seule bonne rétroaction qui existe actuellement est la communication des relations hiérarchiques, déplaçant les nœuds vers l'intérieur et vers l'extérieur en fonction de sa demeure hiérarchique, qui est bien sûr déjà dans la nature des structures arborescentes.
Question
J'apprécierais une contribution à ce sujet.
- Comment puis-je communiquer clairement la structure de l'arbre et de quel type est un nœud?
- Peut-être avez-vous vu une arborescence similaire qui avait une bonne solution au problème?
- Si je veux utiliser des icônes, qu'est-ce qui différencierait intuitivement une icône-client d'une Icône utilisateur ?
Si vous pensez que vous pourriez fournir des commentaires informatifs ou des suggestions de Nice UX sur l'une de ces requêtes, je l'apprécierais grandement.
En regardant l'image, quelques choses me viennent à l'esprit:
- Aplatissez la hiérarchie. Votre hiérarchie est profonde et les arbres (profonds) sont difficiles à utiliser
- Votre arbre n'est pas clair, car il répète les mêmes nœuds à différents niveaux. Débarrassez-vous de la répétition. Pour moi, ce que cela signifie réellement n'est pas clair. Essayez-vous de représenter un réseau dans un widget arborescent?
- Si vous devez utiliser un arbre, utilisez-en un qui utilise des conseils visuels pour connecter des nœuds d'un certain niveau. Pouvez-vous vraiment juger du parent de votre nœud GM?
Addendum
Si je vous comprends bien, vous devez afficher une structure de données des nœuds client, où chaque client peut avoir à la fois des utilisateurs et d'autres clients. Droite?
Une façon de simplifier beaucoup l’arbre est de se débarrasser du niveau intermédiaire que vous avez maintenant dans votre arbre: les éléments Utilisateurs et Clients. Parce que ceux-ci se répètent tout au long de l'arbre, ils confondent plus que ce qu'ils aident. Si vous placez les clients directement sous d'autres clients, l'arborescence devient déjà beaucoup plus simple. Cependant, vous aurez besoin d'une distinction entre les clients et les utilisateurs, bien sûr. L'utilisation d'une icône différente et le tri des clients au-dessus des utilisateurs dans l'arborescence seraient utiles. Comparez la façon dont les dossiers et les fichiers sont distingués dans un gestionnaire de fichiers.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Une étape supplémentaire pourrait être de simplement séparer l'affichage des clients et de leurs utilisateurs, où vous avez les clients dans une arborescence et les utilisateurs dans une liste à côté:
Tout cela suppose bien sûr qu'il n'y ait pas de relation client circulaire, sinon vous vous retrouvez avec une profondeur d'arbre infinie. Si tel est le cas, vous n'avez pas de véritable hiérarchie d'arborescence mais un réseau, et peut-être devriez-vous l'afficher comme tel.
Peut-être que vous ne voulez pas de contrôle d'arborescence. Les contrôles d'arborescence sont les meilleurs pour les utilisateurs modifiant la hiérarchie à une profondeur arbitraire (par exemple, lors de la création et du déplacement de dossiers de fichiers). Je ne sais pas quelle est la tâche utilisateur ici, mais voici quelques possibilités:
I # 1. Sélection d'entité connue
Si le but de l'interface utilisateur est de sélectionner une entité connue (par exemple, un client) pour un travail ultérieur, les arbres peuvent être un moyen gênant de faire une sélection, nécessitant que l'utilisateur "explore" un grand nombre d'informations non pertinentes. Considérez une boîte de dialogue de recherche dans laquelle les utilisateurs entrent n'importe quel sous-ensemble de:
L'identifiant d'entité (ou sous-chaîne)
Que ce soit un utilisateur ou un client
De qui est un utilisateur ou un client
Cela donne une liste de correspondances à sélectionner par vos utilisateurs. Cela est préférable lorsque vos utilisateurs savent ce qu'ils recherchent, par exemple, un nom d'entité ADMVO. Ils peuvent taper "ADMVO" dans le champ vide identifiant de recherche et obtenir le résultat souhaité. Inutile de penser: "Qui est encore ADMVO client?" Néanmoins, il peut également être utilisé lorsque vos utilisateurs ne peuvent pas se souvenir de l'identifiant mais savent que l'entité est client ou utilisateur de quelqu'un d'autre et qu'ils le reconnaîtront lorsqu'ils le verront. Je suppose que vos utilisateurs ne pensent pas en termes de niveaux de relation multiples tels que "Je sais que l'entité que je veux est un client d'un utilisateur de Ford" ou "J'ai besoin de récupérer tous les clients des clients des utilisateurs des clients de GM. " Cela semble tout simplement impossible pour l'homme.
I # 2. Exploration du résea
Si le but de l'interface utilisateur est d'explorer et de modifier les relations entre les entités, l'interface utilisateur dépend de la structure des relations. Votre exemple suggère que vous n'avez pas du tout de hiérarchie, mais une structure de réseau de relations. C'est le cas si une entité donnée (par exemple, Volvo) apparaît sur plusieurs succursales (par exemple, c'est un client de Ford mais également un utilisateur de GM, et peut-être aussi un utilisateur au niveau du système). Je suppose que vos utilisateurs seront confus par les arbres où la même "feuille" apparaît sur les différentes branches - cela casse la métaphore de l'arbre.
UI # 2a Si votre réseau est relativement clairsemé (pas beaucoup de connexions entre les entités), alors considérez un diagramme de liaison de nœud que les utilisateurs peuvent zoomer, pan et filtre. Les pointes de flèche sur les liens peuvent indiquer qui est un client/utilisateur de qui, et les formes des pointes de flèche (par exemple, creux par rapport à rempli) ou des lignes (par exemple, solide par rapport à pointillé) peuvent coder le type de relation (utilisateur ou client). Une palette d'outils fournit des outils de pointeur pour ajouter de nouveaux liens, et n'importe quel lien peut être sélectionné pour être déplacé ou supprimé.
UI # 2b Si le réseau est trop dense pour le nœud-lien (de nombreuses interconnexions), alors envisagez une grille carrée avec des entités répertoriées à la fois en haut de la colonnes et en bas des lignes. Les entités dans les rangées sont des utilisateurs/clients potentiels d'entités d'en haut. Cellules du type de code de grille de la relation entre chaque paire d'entités. Les utilisateurs peuvent effectuer un panoramique et filtrer la grille. Vos utilisateurs peuvent sélectionner n'importe quelle cellule et modifier les relations via les commandes de menu.
Pour les deux # 2a et # 2b, vos utilisateurs peuvent sélectionner une entité et ouvrir une fenêtre pour elle montrant ses détails (attributs).
I # 3. Comparaison et modification des enfants
Si le but de l'interface utilisateur est d'étudier et de modifier les attributs des enfants (utilisateurs et/ou clients) d'une entité donnée, alors envisagez une interface maître-détail avec trois volets. Le volet supérieur fournit des attributs pour une seule entité (qui peut avoir été sélectionnée à l'aide de l'interface utilisateur n ° 1). Le volet suivant répertorie les utilisateurs et leurs attributs dans une présentation tabulaire, et le dernier volet répertorie les clients et leurs attributs dans une présentation tabulaire.
Vos utilisateurs peuvent afficher, comparer et modifier les attributs des utilisateurs ou des clients directement dans les tableaux. Placez les tables dans des expandeurs et vos utilisateurs peuvent afficher ou masquer des clients ou des utilisateurs selon les besoins, un peu comme le permet un arbre. Vos utilisateurs peuvent modifier les relations en coupant/copiant/collant des entités sélectionnées d'un volet enfant à un autre (y compris un autre dans une fenêtre différente pour une entité parent différente).
Comme dans l'interface utilisateur n ° 2, les utilisateurs peuvent sélectionner n'importe quelle entité dans l'un des volets enfants et ouvrir une fenêtre pour obtenir des détails sur cette entité (par exemple, qui sont ses clients et utilisateurs).