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 categorize them in the following ways:
Have you ever come across a particularly elegant way of doing this that allows the user full freedom to define their own categories and values?
Obviously, there will many be trade-offs to make in any design. For example, a learnable design might not be efficient, and vice versa. Or some designs may be more demanding of real estate than others. And some will take significantly longer to develop than others.
Regardless, if you've seen -- or designed -- a good pattern for this, I'd be interested to hear about it. If you have screenshots, all the better.
Attempt at clarification: tags are indeed a great way of categorizing things, but in all implmentations I've seen, there's only ever one level of tagging. The user doesn't generally get to define a category/property and the item's value in that category. To use the example above and StackOverflow's tagging, you'd tag a car as "blue", "sedan", "4", and so on. StackOverflow would have no inherent knowledge that an item couldn't be tagged as both "sedan" and "coupe".
The interface I'm thinking of would need to know that kind of thing, so the user-defined attributes suggestion is more along the lines of what I'm thinking. I'm just keen to find a concrete example of how that kind of system could be elegantly implemented (in a desktop app, if that makes a difference).
Is that any clearer? If not, leave a comment and I'll try to clarify again. :)
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.
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".
I'd suggest a tagging system similar to the one here on stackoverflow. Allow them to tag the images, then view by tag, or combination of tabs. When viewing the page, show thumbnails of the images and the tags for that image below it.
Edit: Based on your clarifications you could have types of tags. When the user defines their own tag, they would need to specify which type it derivies from. With that in mind, you would need limit tags to only one of that type.
TagType { Color, Seats, BodyType, Seats }
TabSubType { Color-Red, Color-Blue, Color-Green, Seats-2, Seats-4, ... }
When a user wants to add tag an image give them a drop down with the TagType. Below that give then another drop down with the TabSubTypes. Give them an option to "Define New" which will cause a textbox to appear where they can type in a new type.
I'd also add these options to the context menu so users can view the tags in a tree style menu. You could also grab the keypress even when an image is focused, look up the TagType and TagSubType name and present a menu of options to choose from. If no matches are found, offer a "Click to add new tag" option.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With