Faucet Facets: Best practices for multifaceted navigation

In "Faucet Facets", Jeffrey Veen proposes that there are better alternatives to rigid hierarchies (i.e. those that don't support multiple parents or broad terms (i.e. polyhierarchy)). Faceted classification being all the rage with IAs these days, he proposes best practices for designing navigation based on a faceted approach.

Veen offers a few examples of search interfaces that offer options based on categories for classifiying products. The Kohler faucet search is a decent one. Different aspects of faucets are presented as search facets. The pool of available faucets is narrowed down based on the selection of descriptors selected under each facet. Veen stresses the importance of allowing your users continual access to these facets in their search process in order to continue narrowing down their results without having to start their search over.

Finding usable and effective ways to surface the classfication fields in a database structure is one thing to consider. When you look at the experimental facet matrix interface of the Flamenco Browser, you see the challenge that a rich set of facets presents. But, in my opinion, creating the metadata schema and developing the facets and terms is the really time consuming and costly stuff.

The faceted approach has been shown lately using products as examples, e.g. wine and faucets. Products are a nice and easy kind of object/entity to use as an example. But taking a faceted approach with documents presents much more of a challenge, especially when it comes to the description of abstract facets such as subject. Descriptions based on observable empirical data should pose little problem (product/document name, date of publication, etc.), but what concerns me is how you enable clients to arrive at facets based on aboutness descriptions -- this is no small task when it comes to documents. Suggesting to your client that a facet-based classfication will aid in the discovery of their objects/entities is a good idea. Giving them the means to classify those objects is another. And perhaps this is where the meat of your services come in. Do you do this work for them or do you give them the means to do it themselves. I guess the approach depends on the corpus of stuff you need to describe and the ability of your client to invest in classification and take on the ongoing task of classifying. I'd be interesting in hearing about people's experiences with enabling clients to do this sort of work.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

client experience

I had no trouble at all explaining facets and their value to a current client; I'd expected it would be difficult. The really hard thing, as usual, is understanding content well enough quickly enough to help clients organize concepts into facets.

Yes, the trick also is setting up their thesaurus/facet database and explaining how to maintain it. "No, you really want to make sure you put *this* in *here* not *over here* because blah blah." "No, you shouldn't just keep adding new top-level facets whenever you want. That's why we spent all that time trying to get them right six weeks ago." I worry that they will dink it all up...

I'm working on a project for the Microelectronics Packaging Industry right now, and that's some dense, technical stuff. Maintaining a facet system for this will require expert-level involvement pretty much as long as the thing is running; that might or might not happen.

We took a couple of measures in trying to make the facet-maintenence UI as simple as possible. Users have to explicitly drill-down into a heirarchy before editing terms; even though there's a LOT more clicking than there might be, it means that there's less confusion about what's being edited. Also, we decided against any sophisticated functions to duplicate terms, sections of the heirarchy, and didn't allow "batch" editing of terms; even though, again, that means more click-and-type work for the user, it hopefully will pay off in fewer chances to mess things up badly.

I think one of the no-tech UI features that is getting attention in all the facet discussion is "results prediction": a link that says "Chrome Faucets (20 products)" is more helpful than one that just says "Chrome Faucets."

And as per usual, don't forget to check out Travis Somebody's Facetmap.com including the build-your-own facet example.

Thanks. Some observations from the info. services world...

Thanks for sharing your experiences, Andrew. I currently work for an info services/digital library org whose major service is to provide classification resources to a corporation. Essentially we develop/maintain the corporate taxonomy, warehouse and classify vendor-supplied data feeds and corporate business unit data base content, and help business units to self-classify content using the business taxonomy.

I think there are three areas of major concern when it comes to classification in the enterprise, assuming you're not going with pure auto-classification methods: 1) creating classification schemas and vocabularies, 2) creating methods and mechanisms to enable customers to classify content themselves, and 3) getting customers to classify their content.

Where I work, our people have generally worked with people in the business units to develop branches of the taxonomy and have provided a methodology and mechanism for customer-contributed indexing. The mechanism provides various levels of auto-classification/filtering, but the real intellectual work is done by humans classifying documents as they are entered into databases -- either librarians or authorized users doing self-publication. We have not implemented many systems where there is open self-publication without authorization, because the groups we work with are usually well defined.

Having said all the above, the issue I am concerned with really is maintenance. As you mention, the task of maintaining a classification system is in getting your customer to understand its value and to develop it in a way such that it retains its value in getting information out. This is time-consuming and costly and often involves having subject matter experts working (ideally full-time) as managers of the classification system. In the short term that I've been exposed to taxonomies in the enterprise (about 4 1/2 years now) it has seemed that the development and maintenance of taxonomies is successful when managed by a small group of subject-matter experts. I think the jury is still out regarding the issue of getting users to actually classify documents they load into your database using your taxonomy. The issue on that is whether they have the luxury of investing the time to understand your taxonomy enough to implement it. If the taxonomy is rich with numerous nodes/terms, this may not be realistic in the hands of many users who are already stretched to do their expected/deliverable work.