Визуальный дизайн иерархии

Ваш базовый элемент управления деревом оказался очень успешным для демонстрации иерархических отношений. Это относительно легко освоить для новичков, и теперь это стандарт де-факто для иерархий. Это очень удобно для редактирования отношений, особенно с помощью перетаскивания. Это, пожалуй, единственный жизнеспособный выбор, когда иерархическая глубина произвольно варьируется в зависимости от объекта (т. е. для любого объекта на дереве могут быть дети, внуки, правнуки и так далее до неопределенного количества «поколений»). ).

Основной альтернативой дереву является окно с главными и подробными панелями. В этом дизайне одна панель содержит родительские объекты, а другая содержит дочерние объекты. Выбор родительского объекта заполняет дочернюю панель его дочерними элементами. У вас могут быть внучатые панели и панели правнуков по мере необходимости, но основные детали обычно работают лучше всего, когда в иерархии есть небольшое фиксированное количество слоев. Пользователи редактируют отношения родитель-потомок, перетаскивая и вырезая/копируя и вставляя дочерние объекты внутри или между окнами, аналогично использованию элемента управления деревом.

Мастер-детали обычно лучше, чем деревья, в следующих случаях:

• Вам нужно показать несколько свойств или атрибутов с каждым объектом. Например, для данного объекта проекта вы хотите указать не только номер сотрудника для каждого члена команды, но также их соответствующие имена, роли, должности, подразделения и фотографии. С помощью master-detail каждую панель можно представить в виде таблицы или формы, что позволит вам многое показать о каждом объекте. Элементы управления деревом часто прибегают к неэффективным и запутанным диалоговым окнам свойств для достижения этой цели.

• Вам нужно разделить детей. Например, для данного объекта проекта вы хотите, чтобы члены его команды были отделены от его этапов проекта. С помощью master-detail у вас может быть две или более дочерних панели для одной родительской панели, причем одна панель содержит список членов команды, а другая — этапы. Неудобно держать несвязанные дочерние объекты отдельно с помощью элемента управления деревом.

• У вас есть отношения «многие ко многим», где у каждого дочернего элемента может быть несколько родителей, а у каждого родителя может быть несколько дочерних элементов. Например, у каждого проекта есть несколько сотрудников (как членов команды), но каждый сотрудник может работать над несколькими проектами. У вас может быть окно с проектами на родительской панели и участниками группы на дочерней панели или с сотрудниками на родительской панели и назначениями проекта на дочерней панели, или вы можете иметь оба окна. Древовидные элементы управления могут сбить пользователей с толку при наличии отношений «многие ко многим», поскольку пользователи не ожидают, что один и тот же дочерний элемент будет находиться под более чем одним родителем.

TreeGX — это удобный способ отображения иерархических данных, отличный от стандартного дерева — ссылка здесь .

Я использую компонент для представления результатов поиска, и хотя он НЕ бесплатен, он стоит денег, если вы хотите представить что-то уникальное.

Вы можете добавить дизайн в стиле визуальной блок-схемы, чтобы сделать его более привлекательным. Как далеко вы хотите зайти, зависит только от вас. Это поможет вам с несколькими родителями.

Ваш вопрос рассматривает вашу проблему дизайна так, как будто это абстрактная вещь. К сожалению, это не так просто - если бы было одно идеальное решение!

Дизайн пользовательского интерфейса очень контекстуален. Вы должны думать о группе пользователей (т. е. об их потребностях, целях и ожиданиях) и о типе деятельности, которую вы пытаетесь поддерживать (т. е. что именно пользователь делает, когда просматривает это дерево? Какова их цель? Собираются ли они использовать ваше приложение ежедневно или раз в год? и т. д.). То, что работает в вашем контексте, может не работать в другом месте.

Люди всегда разочаровываются, когда им говорят "создайте быстрый прототип и протестируйте его на выборке ваших конечных пользователей". Это предполагает дальнейшую работу и выходит за рамки привычной зоны комфорта разработчика. Однако это единственный способ убедиться, что ваш пользовательский интерфейс подходит для данного контекста.