I’ve been lurking on the IAI’s mailing list for some time now, but recently someone posted a question that I just couldn’t resist answering:

We are getting ready to roll out a new faceted search option and I’ve been asked to make recommendations regarding the order of the facets and their characteristics.  I am having a hard time finding specific information about standards or best practices.  I repeatedly come across Stephanie Lemieux’s recent article, Designing for Faceted Search, stating that both facets and values should be based on importance.  While this is great, can anyone point me toward supporting information or is this something that is just understood?  Are there general guidelines for when to list characteristics alphabetically versus when to list them in descending order?

Ok, good call on the poster’s part – I had been vague in my article (Designing for Faceted Search, originally published in KM World), mainly because I had a broad audience and a word count limit. But I supposed that I should clarify a bit…  Here’s my response:

Re: facet order… There are no uber-best practices in terms of what order facets should go in other than “importance” simply because everyone’s context is different. In some contexts, there are some good rules of thumb… Like on an e-commerce site, product type should always be the first facet. In a multi-content/federated search context, content type, doc type or asset type is usually first (e.g. Libraries). Intranets often put departments of origin first. Beyond this, you’re stuck having to do some user-research to figure out what order facets should go (as others have mentioned). Given what they are looking for, what perspectives do users gravitate towards first for refinement? Is it subject? Geo region? You can get a sense of this simply by doing a few interviews. For a recent e-commerce project I did, we took each product type individually and had custom orders – for bedding, the size of the bed was most important (e.g. Queen, king, etc.), then the thread count, then the price, etc. I know the e-commerce examples are a bit tired, but you can extrapolate from this for other contexts.

Re: value order… This is a little more straightforward. To me, the whole strength of faceted search is in automatically presenting what is assumed to be the most meaningful choices first, and usually this is in decreasing volume of corresponding items in the results (a version of “popularity”, and typically the default for many faceted search engines). Typically, you are only showing the first 5-7 options of any facet at once, so it becomes more important to show the ones with the most bang at the top. If you do alpha, you risk showing options that only have a few documents associated to them and wasting that space or forcing another click for a larger number of people. So, I very rarely do alpha (I’ve done it once for Geographic regions, and once for brands, and only once the full list was expanded). If you are not doing true faceted search (with facet values automatically derived by the result set and numbers of documents for each showing beside the label) and doing something more static or navigational, then you can use more custom ordering (e.g. marketing value, putting better selling items first). Or if you are wrestling with a faceted search engine that doesn’t do decreasing volume sorts, then you’ll have to get creative and alpha may be a better default.

If any of you want to contribute more faceted search best practices, please do so in comments and I’ll compile them into a new list.

For more info, there’s a journal article by Marti Hearst (Design Recommendations for Hierarchical Faceted Search), or you can listen to Richard Tomlinson (Endeca) and I present on this webinar.

I just finished moderating the Digital Motion Picture Metadata Symposium at AMPAS.  The day covered all aspects of metadata from pre-production through production, post, distribution and archiving.

We had presenters from Pixar, Sony Pictures, the Academy of Motion Picture Arts and Sciences, Marvel Studios,  Warner Brothers, CNRI, Gracenote and the Library of Congress.

We saw examples from productions including The Incredibles, Wall-e, The Curious Case of Benjamin Button, Syriana, Ocean’s Eleven and others.

The day was packed with presentations that addressed all aspects of the metadata lifecycle for Digital Motion Pictures.

Digital Motion Picture Metadata Lifecycle AMPAS Symposium

Podcast and session summaries coming soon.

I had the great pleasure of doing a podcast a few weeks ago with Paul Miller, podcaster for Nodalities (magazine & blog), on hybrid approaches to folksonomy and taxonomy and their role in the enterprise.

We discussed the now tired debate of folksonomy vs. taxonomy, and focused on the strengths and applications of each approach. I covered how organizations are leveraging social tagging and what some of the pitfalls are in the enterprise context.

I also talk a lot a few of the hybrid approaches to taxonomy & folksonomy:

• Co-existence
• Tag-influenced taxonomy
• Taxonomy-influenced tagging
• Tag hierarchies

I cover some interesting examples and tools (ZigTag, Flickr & Library of Congress), as well as the new directions in “intelligent tags”, like MOAT.

You can hear more about these approaches at the Semantic Technologies conference next week, where my colleagues Paul Wlodarczyk and Richard Beatch will be presenting on the topic on my behalf. Listen to the podcast…

Follow me on Twitter: @stephlemieux, @earleytaxonomy

Thanks to my wife, I’ve been learning a little bit about systems engineering, a form of engineering that addresses the complex interactions of multiple systems. As she says, you need to consider systems engineering when the interrelationships between systems are as complicated as the systems themselves. For example, to reduce automotive traffic you need to research social behavior, road design, business, and the environment. To study ergonomics you need to study the human body, computer design, application design, and user efficiency needs. And don’t get me started on the U.S. healthcare system.

The very first step of systems engineering is to understand the full scope. Ground transportation isn’t about cars and trains, for example, but about the entire surface of the earth: population clusters, topography, climate, and distances. Taxonomy starts this way too, with facets like people, documentation types, product lines, and access levels.

Or at least it should. Sometimes it’s easier to look at a single component of your world and tabulate it in isolation — department offices, account records, HR data — and imagine someday expanding to something larger. But this doesn’t work, not in the long run.

I did some in-house taxonomy work for a client that had two completely different product lines, among others. One product line was based on people. One product line was based on homes. (For example, imagine a telecommunications company that sells mobile phones to individuals, but installs land lines into buildings.) Each product line was managed by smart people who understood the value of taxonomy; they knew just how badly their departments needed a taxonomy with controlled vocabularies. But it took an independent like me to see the real problem: the departments were completely unable to work together. Why? Because the unique identifiers for the people-based line used people-based IDs — like social security numbers — and the home-based line used street addresses. It was impossible to adequately study the calling behavior of individuals, for purposes of cross-selling and product research.

Not surprisingly, the systems engineering process is the same as the taxonomy process, from input collection and requirements analysis to database design and governance. And in fact, for systems to work together, they need a common language, whether it’s a coordinate system or a list of reserved keywords. As complexity grows, the demand for systems engineering and taxonomy grows too, and in our globalized (dare I say universal) space both are growing very fast these days. Investigation into ever-more-complicated systems is necessary for innovation, and our challenge as participants in this growth is to keep looking for the ever-more-encompassing big picture.

If a taxonomy is a tree, then an enterprise taxonomy is the forest, and you know what they say about seeing the forests despite the trees.