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 il semble comme une mise en page d'arbre de vanille de base est la façon la plus intuitive d'aller. Mais je me demande si quelqu'un peut suggérer d'autres approches.

Les exigences seraient,

1) démontrer clairement à l'utilisateur les relations parent / enfant de la liste 2) permettre à l'utilisateur de déplacer facilement les articles autour (que ce soit par glisser-déposer ou une autre méthode) 3) En supposant que vous aviez des données hiérarchisées qui avaient plusieurs parents, comment cela changerait-il votre choix?

Merci tout le monde! - Kevin

Était-ce utile?

La solution

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

L'alternative primaire à arbre est une fenêtre avec des panneaux maître-détail. Dans cette conception, un volet contient des objets parent et un autre contient les objets enfants. La sélection d'un objet parent remplit le volet de l'enfant avec ses enfants. Vous pouvez avoir des vitres grand-enfant et vitres arrière-grand-grand-enfant au besoin, mais maîtres détails travaillent généralement mieux quand il y a un petit nombre fixe de couches à la hiérarchie. Les utilisateurs modifier les relations parent-enfant par glisser-déposer et couper / copier et coller des objets enfants soit à l'intérieur ou entre les fenêtres, semblables à l'aide d'un contrôle d'arborescence.

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

  • Vous devez présenter des propriétés multiples ou attributs à chaque objet. Par exemple, pour un objet projet donné, vous voulez la liste non seulement le numéro d'employé pour chaque membre de l'équipe, mais aussi leurs noms respectifs, rôles, titres, les divisions et les photographies. Avec un maître-détail, chaque panneau peut être posé comme une table ou un formulaire vous permettant de montrer beaucoup de choses sur chaque objet. contrôles d'arbres ont souvent recours à des boîtes de dialogue Propriétés inefficaces et confus pour ce faire.

  • Vous devez diviser les enfants. Par exemple, pour un objet projet donné, vous voulez garder ses membres de l'équipe séparée de ses étapes du projet. Avec un maître-détail, vous pouvez avoir deux ou plusieurs panneaux enfants pour un volet parent unique, avec un panneau listant les membres de l'équipe et une liste des étapes. Il est difficile à garder l'enfant sans rapport avec des objets séparés avec un contrôle d'arborescence.

  • Vous avez beaucoup à beaucoup de relations, où chaque enfant peut avoir plusieurs parents, ainsi que chacun des parents ayant plusieurs enfants. Par exemple dire que chaque projet a plusieurs employés (comme membres de l'équipe), mais chaque employé peut travailler sur plusieurs projets. Vous pouvez avoir une fenêtre avec des projets dans le volet des parents et des membres de l'équipe dans le volet des enfants ou des employés dans le volet des parents et missions du projet dans le volet de l'enfant, ou vous pouvez avoir les deux fenêtres. contrôles d'arbres peuvent dérouter les utilisateurs quand il y a beaucoup à plusieurs relations parce que les utilisateurs n'attendent pas le même enfant d'être sous plus d'un parent.

Autres conseils

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

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.

Vous pouvez mettre une certaine conception de style de diagramme de flux visuel pour le rendre plus attrayant. Dans quelle mesure vous voulez aller est totalement à vous. Cela vous aidera à plusieurs parents.

Votre question traite votre problème de conception comme si elle est une chose abstraite. Malheureusement, ce n'est pas aussi simple que cela - si seulement il y avait une solution parfaite

Le design est très interface utilisateur contextualisée. Vous devez penser au groupe d'utilisateurs (c.-à leurs besoins, les objectifs et les attentes) et le type d'activité que vous essayez de soutenir (à savoir ce qui est exactement l'utilisateur fait lorsqu'ils naviguent sur cet arbre? Quel est leur but? Vont-ils utiliser votre application quotidienne ou une fois par an? etc). Ce qui fonctionne dans votre contexte peut ne pas fonctionner ailleurs.

Les gens sont toujours déçus quand on lui dit « aller construire un prototype rapide et le tester sur un échantillon de vos utilisateurs finaux » . Il implique un travail plus loin et à l'extérieur de la zone de confort d'un développeur typcial. Cependant, il est le seul moyen d'être sûr que votre interface utilisateur est adaptée à votre contexte donné.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top