Самый элегантный интерфейс для классификации предметов? - PullRequest
8 голосов
/ 11 ноября 2008

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

  • Цвет (красный, серебристый, синий, черный и т. Д.)
  • Кузов (люк, седан, купе, универсал и т. Д.)
  • Сиденья (2, 4, 5, 6 и т. Д.)
  • и т.д.

Вы когда-нибудь сталкивались с особенно элегантным способом сделать это, который дает пользователю полную свободу определять свои собственные категории и ценности?

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

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

Попытка разъяснения : теги действительно отличный способ категоризации вещей, но во всех случаях, которые я видел, существует только один уровень тегирования. Обычно пользователь не может определить категорию / свойство и значение элемента в этой категории . Чтобы использовать приведенный выше пример и пометку StackOverflow, вы должны пометить автомобиль как «синий», «седан», «4» и т. Д. StackOverflow не знает, что предмет не может быть помечен как «седан» и «купе».

Интерфейс, о котором я думаю, должен знать подобные вещи, поэтому предложение пользовательских атрибутов больше соответствует тому, что я думаю. Я просто хочу найти конкретный пример того, как такая система может быть элегантно реализована (в настольном приложении, если это имеет значение).

Это понятнее? Если нет, оставьте комментарий, и я постараюсь уточнить еще раз. :)

Ответы [ 7 ]

9 голосов
/ 12 ноября 2008

Похоже, у вас есть две задачи: Задача 1 Категоризация объектов, где для серии объектов пользователь назначает каждому категорию (значение) для каждого из нескольких измерений (атрибутов). Задача 2. Создание и изменение измерений и категорий.

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

Первый ключевой вопрос заключается в том, чтобы выяснить с помощью пользовательского исследования, являются ли задачи 1 и 2 интегрированными или отдельными.

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

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

Возможно, вы захотите, чтобы кнопка скрывала / отображала списки категорий, поскольку это может занимать много места (даже при использовании полос прокрутки). Даже если задачи 1 и 2 тесно интегрированы, я думаю, вы обнаружите, что пользователи могут иногда хотеть убрать списки категорий.

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

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

Окно для Задачи 2 может быть похоже на часть заголовка для Задачи 1. Это согласуется с таблицей, используемой для Задачи 1, и позволяет пользователям видеть категории для нескольких измерений одновременно, помогая им определить наилучшую схему категоризации (например, помочь им найти, где по существу одна и та же категория появляется в двух разных измерениях). Однако, если пространство представляет собой проблему, рассмотрите список измерений, каждое из которых показывает список категорий в отношении мастер-деталь.

УльтимаТо, что пользовательский потенциал и гибкость для Задачи 2 - древовидное управление. Корневой уровень дерева содержит измерения, а следующий шаг в иерархии включает категории в каждом измерении. Основным преимуществом является то, что он поддерживает размеры в зависимости от категорий. Например, у кого-то может быть измерение Тип транспортного средства, которое включает такие категории, как Автомобиль, Лодка, Самолет и т. Д. Для категории «Автомобиль» может быть измерение «Тип кузова» с категориями, которые применяются только к этой категории (Купе, Хэтчбек и т. Д. ). Зависимые измерения представлены в дереве ответвлениями от категории. В результате дерево чередуется между измерениями и категориями с каждым уровнем в.

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

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

Пользователь работает намного лучше, если в культуре, организации или области уже есть соответствующая многомерная схема (например, для автомобилей). Конечно, если схема уже существует, вы можете исследовать ее и установить в качестве набора параметров по умолчанию в своем продукте. Задача 2 должна поддерживаться только для того, чтобы опытные пользователи могли ее точно настроить.

4 голосов
/ 11 ноября 2008

Вы можете использовать теги : пользователь должен пометить каждое изображение, а затем показать набор миниатюр изображений, отсортированных по тегам.

Возможно, более сложным, чем теги, будет набор пользовательских атрибутов. Например, вместо того, чтобы пометить изображение «красным», пометьте его атрибутом «color = red».

1 голос
/ 11 ноября 2008

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

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

Чтобы понять, как это работает в пользовательском интерфейсе, взгляните на Facetmap. Я не могу поручиться за их продукт, потому что я не использовал его, но я реализовал нечто подобное для своих собственных приложений с хорошими результатами.

http://www.facetmap.com/

Опять же, идеи, стоящие за граненой классификацией, заслуживают большего внимания, и я знаю, что здесь я не оправдываю их. Для занимательной обработки предмета Клэем Ширки, послушайте «Онтология переоценена»:

http://itc.conversationsnetwork.org/shows/detail470.html

1 голос
/ 11 ноября 2008

Я бы предложил систему тегов, аналогичную той, что здесь используется в stackoverflow. Разрешить им помечать изображения, а затем просматривать по тегам или комбинации вкладок. При просмотре страницы показывайте миниатюры изображений и теги для этого изображения под ней.

Редактировать: на основе ваших разъяснений у вас могут быть типы тегов. Когда пользователь определяет свой собственный тег, ему нужно будет указать, к какому типу он относится. Имея это в виду, вам нужно будет ограничить теги только одним из этого типа.

TagType { Color, Seats, BodyType, Seats }
TabSubType { Color-Red, Color-Blue, Color-Green, Seats-2, Seats-4, ... }

Когда пользователь хочет добавить метку к изображению, дайте ему выпадающий список с TagType. Ниже приведем еще один раскрывающийся список с TabSubTypes. Дайте им возможность «Определить новый», что приведет к появлению текстового поля, где они могут ввести новый тип.

Я бы также добавил эти параметры в контекстное меню, чтобы пользователи могли просматривать теги в древовидном меню. Вы также можете захватить нажатие клавиши, даже когда изображение сфокусировано, найдите имя TagType и TagSubType и представьте меню опций на выбор. Если совпадений не найдено, предложите вариант «Нажмите, чтобы добавить новый тег».

0 голосов
/ 10 декабря 2015

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

Пользователь должен иметь возможность импортировать список и создавать измерения для списка, а затем интуитивно классифицировать список на основе этих измерений. Создание измерений будет состоять из присвоения имени / переименования измерения (имя столбца), а затем добавления / переименования / удаления категорий (элементов столбца) этого измерения. Должно быть легко переключаться между созданием новых измерений и фактической категоризацией элементов списка по отдельности или в совокупности, используя новые измерения, созданные пользователем. Затем пользователь может экспортировать список с дополнительным столбцом или столбцами (измерениями), содержащими вновь созданные категории.

Идея состоит в том, что было бы намного удобнее для пользователя, чем просто иметь таблицу и добавлять к ней столбцы. В идеале вы сможете выбрать элементы в списке, а затем назначить им проверенный элемент категории из созданного пользователем списка измерений, который автоматически заполнит таблицу только для чтения, которую можно будет экспортировать. Вход = список, Выход = всесторонне категоризированный список. Таблица не требуется.

0 голосов
/ 12 ноября 2008

Хорошо, хорошо, я склонен продолжать об этом слишком много, но тегирование - это всего лишь пример того, что вы можете сделать с тройным графиком, например, используя RDF. Вставить ссылку на Википедию. Теперь я знаю, что вы сказали, что тегов недостаточно, исходя из требований к вложенности, но нет никаких причин, по которым вы не можете далее «тегировать теги» как потомков друг друга.

Car|Tagged_with|Red
Red|Is_child_of|Colours

Таким образом, ваши данные остаются сверхгибкими, и разрыв между данными и метаданными становится размытым.

0 голосов
/ 11 ноября 2008

Я, возможно, неправильно понимаю ваш вопрос, но он не очень похож, если не совсем то, для чего нужны теги (как в переполнении стека и в gmail). Или вы ищете что-то более конкретное, чем это?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...