Visual Design Hiérarchie

Question

J'ai une hiérarchie de catégories, où une catégorie peut avoir un seul parent (et vous pouvez avoir plusieurs niveaux d'enfants.)

J'étudie les moyens d'afficher ces informations à l'utilisateur et semble comme une disposition de base de vanille est la manière la plus intuitive d'aller. Mais je me demande si quelqu'un peut suggérer d'autres approches.

Les exigences seraient,

1) démontrent clairement à l'utilisateur les relations parent de liste/enfant 2) permettent à l'utilisateur de se déplacer facilement des éléments autour (que ce soit par glisser-déposer ou une autre méthode) 3 En supposant que vous ayez des données hiérarchiques ayant plusieurs parents, comment cela changerait-il votre choix?

Merci à tous! - Kevin

Answer 1

Votre contrôle d'arbre de base a été un grand succès pour montrer des relations hiérarchiques. C'est relativement facile à apprendre pour les novices et c'est maintenant la norme de facto pour les hiérarchies. Il est très approprié pour modifier les relations, en particulier avec le glisser-déposer. C'est peut-être le seul choix viable lorsque la profondeur hiérarchique varie arbitrairement par objet (pour tout objet sur l'arbre, il peut y avoir des enfants, des petits-enfants, des arrière-petits-enfants, etc.) à un nombre indéfini de «générations».).

L'alternative principale à arbre est une fenêtre avec des vitres maître-détail. Dans cette conception, un volet contient des objets parents et un autre contient des objets enfants. La sélection d'un objet parent remplit le volet enfant avec ses enfants. Vous pouvez avoir des volets grand-enfant et des panneaux grand-petit-enfant si nécessaire, mais les détails principaux fonctionnent généralement mieux lorsqu'il y a un petit nombre fixe de couches dans la hiérarchie. Les utilisateurs éditent les relations parent-enfant par glisser-déposer et coupent/copient & coller des objets enfants dans ou entre les fenêtres, de manière similaire à l'utilisation d'un contrôle d'arborescence.

Master-détails sont généralement mieux que les arbres pour les cas suivants:

• Vous devez présenter des propriétés multiples ou attributs à chaque objet. Par exemple, pour un objet Projet donné, vous souhaitez répertorier non seulement le numéro d'employé pour chaque membre de l'équipe, mais également leurs noms, rôles, titres, divisions et photographies respectifs. Avec un détail maître, chaque volet peut être présenté sous la forme d'une table ou d'un formulaire vous permettant de montrer beaucoup de choses sur chaque objet. Les contrôles Tree utilisent souvent des boîtes de dialogue Propriétés inefficaces et déroutantes pour y parvenir.

• Vous devez diviser les enfants. Par exemple, pour un objet Project donné, vous souhaitez conserver ses membres d'équipe séparés de ses étapes de projet. Avec un détail principal, vous pouvez avoir deux volets enfants ou plus pour un volet parent unique, avec un volet répertoriant les membres de l'équipe et un autre répertoriant les étapes. Il est difficile de séparer des objets enfants indépendants avec un contrôle d'arbre.

• Vous avez plusieurs-à-plusieurs relations, où chaque enfant peut avoir plusieurs parents ainsi que chaque parent ayant plusieurs enfants. Par exemple, chaque projet a plusieurs employés (en tant que membres de l'équipe), mais chaque employé peut travailler sur plusieurs projets. Vous pouvez avoir une fenêtre avec Projets dans le volet parent et Membres de l'équipe dans le volet enfant ou Employés dans le volet parent et Affectations de projet dans le volet enfant, ou vous pouvez avoir les deux fenêtres. Les contrôles d'arborescence peuvent perturber les utilisateurs lorsqu'il existe des relations plusieurs-à-plusieurs car les utilisateurs ne s'attendent pas à ce que le même enfant se trouve sous plusieurs parents.

Answer 2

Vous pouvez mettre une certaine conception de style de diagramme de flux visuel pour le rendre plus attrayant. Jusqu'où vous voulez aller est totalement à vous. Cela vous aidera avec plusieurs parents.

Answer 3

TreeGX est une manière douce pour afficher les données hiérarchiques d'une façon différente de l'arbre standard - link is here.

J'utilise le composant pour présenter les résultats de recherche et alors qu'il est libre de ne pas il vaut la peine de l'argent si vous voulez présenter quelque chose d'unique.

Answer 4

Votre question traite votre problème de conception comme s'il s'agissait d'une chose abstraite. Malheureusement, ce n'est pas si simple - si seulement il y avait une solution parfaite!

L'interface utilisateur est très contextualisée. Vous devez penser au groupe d'utilisateurs (c'est-à-dire à leurs besoins, objectifs et attentes) et au type d'activité que vous essayez de soutenir (par exemple, que fait exactement l'utilisateur quand il parcourt cet arbre? votre application quotidienne ou une fois par an? etc). Ce qui fonctionne dans votre contexte peut ne pas bien fonctionner ailleurs. Les gens sont toujours déçus quand on leur dit "construisez un prototype rapide et testez-le sur un échantillon de vos utilisateurs". Cela implique des travaux supplémentaires et en dehors de la zone de confort d'un développeur typcial. Cependant, c'est la seule façon de s'assurer que votre interface utilisateur est adaptée à votre contexte.