Most elegant UI for categorizing items?

Question

I have a collection of items that the user needs to group/categorize in several ways. For the sake of an example, let\'s say it\'s a collection of cars and the user wants to cat

Answer 1

You could use tags: Have the user tag each image, then show a set of image thumbnails sorted by tags.

Maybe more advanced than tags would be a set of user-defined attributes. For example, instead of tagging a picture with "red", tag it with an attribute "color=red".

Answer 2

Ok, well, I tend to go on about this too much, but Tagging is just an example of what you can do with a triple graph, eg using RDF. [Insert Link To Wikipedia]. Now I know you said that tags are not enough, based on requirements for nesting, but there is no reason you cannot further "tag tags" as children of eachother.

Car|Tagged_with|Red
Red|Is_child_of|Colours

This way your data remains ultra-flexible, and really the divide between what is data, and what is metadata becomes blurred.

Answer 3

It sounds like you have two tasks: Task 1 Categorize Objects, where for a series of objects, the user assigns each a category (value) on each of multiple dimensions (attributes). Task 2: Create and Modify Dimension and Categories.

Outside of data modelers, object-oriented programmers, and database designers, the idea of dimensions and categories is a very hard concept to grasp. You should be prepared for users not understanding the difference between categories and dimensions. However, users generally will understand tables, where each column is a dimension (that comprises several categories) and each row is an object. As much as possible, work with tables.

The first key question is to figure out through user research is the degree Task 1 and 2 are integrated or separate.

If the tasks are integrated, with users often switching fluidly from one to the other without much thought, then one UI design is to have a objects-by-dimension table, but provide a blank column (or an “Insert” button) to allow the user to add a dimension. The column header has the dimension name, which the user can edit. Under the header is a space listing the categories of that dimension. Each category name is editable and there is a blank line (or the Insert button) to add a new category. Below that are the objects to categorize, each with a dropdown list in each column for dimension.

In usability testing, watch out for users trying to set an object’s category by clicking on a category in the category list, rather than selecting from the dropdown list. Make the category list appear visually separate to prevent this.

You may want a button to hide/show the category lists, as this can take a lot of space (even when using scrollbars). Even if Task 1 and 2 are tightly integrated, I think you’ll find users may want to get the category lists out of the way sometimes.

If you find that Task 1 and 2 are separate, rarely being done together (e.g., users typically set up their dimensions then categorize a bunch of objects), then you’re better off with a separate window (or page) for each task, although it should be easy to navigate back and forth between them. For example, while users may typically set up their dimensions beforehand then rarely modify them, sometimes a user will realized one needs a new category for a dimension while categorizing an unusual object, so you provide a “Add category” menu item that takes the user to the Manage Categories window, with a new category inserted for the current dimension awaiting the user to provide a name.

The window for Task 1 is the same as before: table of objects with a column of dropdown lists for each dimension, but exclude the category lists, the editing of the dimension names, and the capacity to add a new dimension. This is most efficient if the user needs to scan for objects needing categorizing or re-categorizing, or if typically the user needs to compare one object against some others (e.g., to decide how to categorize the object). However, if the user’s task is truly limited to just categorizing an object one at a time based on outside information (e.g., transcribing information from paper), then consider a form rather than a table, showing an array of list boxes, one for each attribute. With a single click of each list box to set each category, this is faster than using dropdown lists.

The window for Task 2 could be like the header portion for task one. It is consistent with the table used for Task 1 and allows users to see categories for multiple dimensions at once, helping them figure out the best categorization scheme (e.g., help them find where essentially the same category appears in two different dimensions). If space is a problem, however, then consider a list of dimensions each showing a list of categories in a master-detail relation.

The ultimate in user power and flexibility for Task 2 is a tree-like control. The root level of the tree comprises dimensions and the next step in the hierarchy comprises the categories within each dimension. The main advantage is that it supports dimensions being dependent on categories. For example, one may have a Vehicle Type dimension that includes categories like Car, Boat, Plane, etc. For the Car category, one may then have a Body Type dimension with categories that only apply to that category (Coupe, Hatchback, etc.). Dependent dimensions are represented in the tree by branches off a category. The result is the tree alternates between dimensions and categories with each level in.

It’s important to visually distinguish the categories from the dimensions, perhaps by different icons, and maybe different font as well –something to tell users that alternating steps in the hierarchy are qualitatively different (e.g., if you create a Dimension, then you should create at least two categories). Even then, provide a means of easy recovery if users confuse dimensions with categories (e.g., allow them to move a bunch of “dimensions” to under another dimension, converting the former into categories).

I want to emphasize again the difficulty people have with abstractions like dimensions and categories. Even when they do understand it, people generally have great difficulty creating decent dimensions and categories on their own. There are complicated interactions that can result that you need to think through (e.g., what happens to object categorization when a category is moved to a new dimension?). If you are expecting each user to truly create their own novel dimensions, then you may want to seriously re-think your whole approach. It is an inherently complicated task.

User do much better if there’s already a relevant multi-dimensional scheme in the culture, organization, or domain (such as we have for cars). Of course, if there already is a scheme, then you can research it and install it as a default set of dimensions in your product. Task 2 only needs to be supported to allow expert users to fine-tune it.

Answer 4

It seems like an issue that needs to be addressed especially for having users classify dimensional data into further, more simplified, dimensions (groups or categories whatever you want to call them) so that they can visualize the data better via the simplified categories/dimensions.

The user needs to be able to import a list, and both create dimensions for the list and then categorize the list intuitively based on those dimensions. Creating the dimensions would consist of naming/renaming the dimension (name of column) and then adding/renaming/removing the categories (column items) of that dimension. It should be seamless to switch between creating new dimensions and actually categorizing the list items individually or in bulk using the new dimensions created by the user. The user could then export the list with the additional column or columns (dimensions) containing the newly created categories.

The idea is that it would be much more user friendly that just having a table and adding columns to it. Ideally you would be able to select items in the list, and then assign them a validated category item from the user created dimension list which would auto-populate a read-only table that could be exported. Input = list, Output = comprehensively categorized list. No spreadsheet required.

Answer 5

Faceted Classification is a way to categorize things that doesn't get the attention it deserves. It allows you to define mutually exclusive categories and provide a value for each content item for each category. For example, you could classify wines by region, varietal, vintage and price, and a user would conduct their search by picking one or more values in one or more categories. For example, “French or Italian reds under $40”. Assuming you have the category data at hand, this is often the most powerful classification and search technique available, better than trying to fit everything into a single hierarchy or relying on tags.

To implement this on the backend, make tables for each category and fill them with the distinct values. Then make a table what has a foreign key to each category table, together with a field that contains the content. This is similar to a “fact” table in dimensional database design.

To get an idea how this can works in the UI, take a look at Facetmap. I can’t vouch for their product because I haven’t used it, but I’ve implemented something similar for my own applications with good results.

http://www.facetmap.com/

Again, the ideas behind faceted classification deserve more attention, and I know I'm not doing them justice here. For an entertaining treatment of the subject by Clay Shirky, listen to "Ontology is Overrated":

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

Answer 6

I may be misunderstanding you question, but isn't that very similar if not exactly what tags are for (as in stack overflow and gmail). Or are you looking for something more specific than that?