Recently I wrote about Denton’s How to Make a Faceted Classification and Put it on the Web. In section 4 he introduces three questions and four principles that provide useful guidance when implementing navigation systems for information architectures that rely on faceted classification.
The three questions step through some basic questions that you need to answer before you set out to design your navigation system.
- Are you designing for free navigation (aka browsing) or navigation by selection (aka searching)?
- What are your facets like?
- Will you give the user control over the citation order?
Characterizing your facets in question 2 is the tricky one. How may facets you have, how they relate to each other, how evenly the foci are distributed, etc. will all inform your decisions when designing a navigation system. Unfortunately there isn’t a check list that matches facet characteristics to best navigation design. You’ll have to experiment.
When thinking about your design decisions Denton offers the four following principles
- Do not allow the user to create a query with no results.
- Show the user where they are.
- Make it easy to adjust or refine the query.
- Use the URL as the notation for the classification.
I can quibble with the details. (A null return is useful — if you can show the user which parts of the query have results and which don’t.) But the principles are always valid points to consider.
I particularly love his fourth principle — that the URL should be a human understandable representation of the foci loaded into the facets that got the user to the current location. Technically a royal pain in the ass to create and some would claim useful only to uber-geeks But think on it. How often have you gone to a bookmarked page and then chopped of the URL’s tail or altered a word or two to get to some place when you didn’t fell like typing some big ole URL? How often have you been frustrated in the attempt?
The particular culprit in most cases of incomprehensible URLs is dynamic web pages — AJAX, PHP, and all their database generated content friends.
A recent client was driven nuts by the fact that when she viewed her site statistics the page names displayed as:
www.(somesite.com)/index.asp?PageAction=VIEWPROD&ProdID=116.
ProdID116 was utterly meaningless to her. As were 95% of the other page names. There was no easy way to force the use of a reasonable facsimile of the product name in the URL. Complex kludging ensued; reports were generated. But not as frequently or accurately as they should have been. All very unsatisfactory.