Иерархия Визуальный Дизайн
У меня есть иерархия категорий, где у категории может быть один родитель (и у вас может быть несколько уровней детей).
Я исследую способы отображения этой информации для пользователя, и кажется, что базовая компоновка ванильного дерева - наиболее интуитивный путь. Но мне интересно, если кто-нибудь может предложить другие подходы.
Требования будут,
1) четко продемонстрировать пользователю родительские / дочерние отношения списка 2) позволить пользователю легко перемещать элементы (перетаскиванием или каким-либо другим способом) 3) предполагая, что у вас есть иерархические данные с несколькими родителями, как это изменится твой выбор?
Спасибо всем! Кевин
4 ответа
Ваш базовый древовидный контроль был очень успешным для показа иерархических отношений. Для новичков это относительно легко изучить, и теперь это де-факто стандарт для иерархий. Это очень удобно для редактирования отношений, особенно с помощью перетаскивания. Это, пожалуй, единственный жизнеспособный выбор, когда иерархическая глубина произвольно варьируется в зависимости от объекта (т. Е. Для любого объекта на дереве могут быть дети, внуки, правнуки и т. Д. С неограниченным числом "поколений").).
Первичная альтернатива дереву - это окно с панелями основной детали. В этом проекте одна панель содержит родительские объекты, а другая - дочерние объекты. Выбор родительского объекта заполняет дочернюю панель ее дочерними элементами. При необходимости вы можете использовать панели "великий ребенок" и "великий ребенок", но основные детали обычно работают лучше, когда в иерархии имеется небольшое фиксированное количество слоев. Пользователи редактируют родительско-дочерние отношения путем перетаскивания и вырезания / копирования и вставки дочерних объектов внутри или между окнами, подобно использованию древовидного элемента управления.
Основные детали обычно лучше деревьев в следующих случаях:
Вам нужно показать несколько свойств или атрибутов с каждым объектом. Например, для данного объекта Project вы хотите указать не только номер сотрудника для каждого члена команды, но также их соответствующие имена, роли, звания, подразделения и фотографии. С помощью master-detail каждая панель может быть представлена в виде таблицы или формы, позволяющей вам многое показать о каждом объекте. Для достижения этой цели древовидные элементы управления часто прибегают к неэффективным и запутанным диалогам свойств.
Вы должны разделить детей. Например, для данного объекта Project вы хотите отделить членов своей команды от этапов проекта. С master-detail вы можете иметь две или более дочерние панели для одной родительской панели, одна из которых отображает членов группы, а другая - этапы. Неловко хранить отдельные несвязанные дочерние объекты с помощью элемента управления деревом.
У вас есть отношения многие-ко-многим, когда у каждого ребенка может быть несколько родителей, а также у каждого из них есть несколько детей. Например, скажем, у каждого проекта есть несколько сотрудников (в качестве членов команды), но каждый сотрудник может работать над несколькими проектами. У вас может быть окно "Проекты" в родительской панели и "Члены группы" в дочерней панели, "Сотрудники" в родительской панели и "Назначения проектов" в дочерней панели, или у вас могут быть оба окна. Элементы управления деревом могут вводить пользователей в заблуждение, когда существуют отношения "многие ко многим", поскольку пользователи не ожидают, что один и тот же ребенок будет иметь более одного родителя.
TreeGX - приятный способ отображать иерархические данные иначе, чем стандартное дерево - ссылка здесь.
Я использую компонент для представления результатов поиска, и хотя он НЕ является бесплатным, он стоит денег, если вы хотите представить что-то уникальное.
Вы можете добавить визуальный дизайн в стиле блок-схемы, чтобы сделать его более привлекательным. Как далеко вы хотите пойти, полностью зависит от вас. Это поможет вам с несколькими родителями.
Ваш вопрос рассматривает вашу проблему дизайна, как будто это абстрактная вещь. К сожалению, не все так просто - если бы было одно идеальное решение!
Дизайн пользовательского интерфейса очень контекстуализирован. Вы должны подумать о группе пользователей (то есть их потребностях, целях и ожиданиях) и типе деятельности, которую вы пытаетесь поддерживать (то есть, что именно пользователь делает, когда просматривает это дерево? Какова его цель? Собираются ли они использовать ваше приложение ежедневно или раз в год? и т. д.). То, что работает в вашем контексте, может не сработать в других местах.
Люди всегда разочаровываются, когда им говорят "иди создай быстрый прототип и протестируй его на примере своих конечных пользователей". Это подразумевает дальнейшую работу и выходит за пределы зоны комфорта типичного разработчика. Однако это единственный способ убедиться, что ваш пользовательский интерфейс подходит именно вам.