Самый элегантный интерфейс для категоризации предметов?

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

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

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

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

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

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

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

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

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

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

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

http://www.facetmap.com/

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

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

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

Car|Tagged_with|Red
Red|Is_child_of|Colours

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

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

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

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