Compared with Hierarchies, it is much easier to describe item so you can find them later in Faceted systems

• Describe items without having to figure out where the item fits into some larger organizational structure of all of your data because describing items is independent of building structure in Faceted systems.
• The ability to label an item in multiple Facets means that you never have to be paralyzed by an inability to choose between two equally valid folder locations in a hierarchy. In a hierarchy, an item can only belong in either the Project Foo folder or the Status Done folder. It can't live in both. In a faceted system, an item can be labeled as both Project: Foo and Status: Done.
• Easy to create a unique description of an item. This in turn means that while it is often unlikely that a single characteristic of an item is enough to differentiate it from all other items (ie. Email from: Jane, a person might have thousands of them), the ability to attach multiple dimensions or facets of metadata to a single item gives you the capacity to construct a "more unique" metadata thumbprint for each item. (ie. Email from: Jane, Date received: Today, Subject includes: Junior league)

Faceted browsers provided a guided navigation experience optimized for pinpointing data

• The ability to slice and dice data in multiple ways amounts to the ability to construct completely different semantically pure hierarchies on the fly. What would take a lot of work in a fixed hierarchy is no effort in a Faceted browser. Faceted browsers are great at flexibly optimizing and re-optimizing themselves for the task at hand, whether it's getting dressed for work, doing your laundry or finding a pair of shorts.
• Footnote: You might think that with search, you wouldn't need to have hierarchy-style guided navigation, even if it is infinitely flexible. However, sometimes you need a little more hand-holding than that. When constructing a search, you're asked to set all of the parameters at once. This works when you know exactly what you're looking for. You can get to your information by directly wormholing to it at warp speed. When you're less clear about what you're looking for (ie. this often a problem in Google when you know what something looks like but you don't know what it's called) you will often conduct a series of searches that iteratively narrow the search results with additional parameters, where the results of each iterative search help provide clues about how to proceed.
• A Faceted browser like the one in iTunes provides essentially the same experience with more hand-holding. Instead of having to sift through pages and pages of search results to figure out how to narrow your search, the Faceted browser is simply a clustering mechanism that explicitly clumps the search results into semantically meaningful groupings (ie. For the Genre: R&B, the songs you have are by these Artists and in these Albums). In other words, instead of using your brain to cluster search results, the system clusters the search results for you.

• OTOH, compared to Hierarchies, Facets are much better at targeted search and retrieval of individual items
• Especially in large, messy hierarchies, it's often hard to remember exactly where you put an item. As a result, people often find themselves hunting through their hierarchies looking for that elusive item.
• In a faceted system, you can pluck items out of the data soup by calling up a few of its Facet or attribute values. This is what we do when we build search queries. A well-constructed search is one that puts together an unique enough thumbprint of the item's attributes.
• It's the difference between looking for Roberto's Taco Stand by walking the streets of San Diego, looking for where Marina Blvd. intersects the rollercoaster versus having Roberto's Taco Stand, the one at the intersection of Marina Blvd. and the rollecoaster in San Diego brought to you.
  • Another way to put it is: You don't have to go to the information, the information comes to you
  • Another variation on this theme: You don't need to know where the information lives, the system knows where it is. You just need to remember a few of it's characteristics and the system brings it to you.

• Imagine the iTunes browser on crack...where you can actually reposition the columns, effectively re-organizing the hierarchy on the fly.
• Fire up the iTunes Browser and step through how it works
• iTunes.png:
  

Where Facets fail: Getting a big picture

Slicing and dicing is great, but... the constant reorientation can be confusing in and of itself: Most people are bad at spatial reorientation and if you think of each facet as a dimension of the data, everchanging rearrangements of facets can be similarly jarring.

• The following is the kind of drawing you might do in a high school drafting class. It is a 3-dimensional cube represented as a series of 2-dimensional drawings, showing all faces of the cubes. Takes a second to put it all together into a cube, doesn't it?
• 3D.png:
  
• Can you tell when the image has made 1 revolution?
• The following image has been taken from: http://synapses.mcg.edu/anatomy/astro3d/astro/A_3D.stm
• 3-D_rotating.gif:
  

Facets make it hard to get a sense of scope

Because the same items appear and reappear depending on which facet of the data you are examining, it is sometimes difficult to get a true sense of the scope and range of your data in Faceted systems. As we will see, this problems gets even worse in Tag-based systems.

Faceted systems don't quite tell a story

• To be fair you have the same multi-level chunking that you get in well-designed hierarchies:
  • Chunking of items into containers and then
  • Further chunking of containers into container types (facets)
• And the chunking is far easier to maintain because the containers and container types are NOT locked into a fixed parent-child structure, but instead co-exist independently
• Similar to well-designed hierarchy levels, a well-designed facet that is filled out end-to-end with minimal overlap can greatly enhance the browsing experience.

However, it is precisely this lack of structure that also means that Faceted systems "don't prioritize" the container types for you the way Hierarchies do and as a result, they fail to go that final mile so crucial to storytelling: a linear dictation of what order to experience the facets in. Instead Faceted systems are designed to allow the user to construct their own storyline.

• Case study: iTunes
  • First, you might figure out that the kind of data you are dealing with is songs, because the facets are: Artists, Albums, Genre, Composer
  • Second, by looking at the range of Containers or Attribute values in each Facet or Attribute, you get a sense of what what kinds of songs you have: Bob Dylan v. Berlin Philharmonic v. Kenny G
• But ultimately, facets fail to give you a sense of the facet foodchain, which a hierarchy of Genre>>Composer>>Artist>>Album does:
  • That Genre is a bigger, more everlasting concept that a Composer, which is inherently an individual person, living in a particular time.
  • And Composer, especially in Classical music is a bigger, more everlasting figure than any individual artist that performs and interprets the work of that Composer. (ie. An analogy might be how certain bureaucrats outlive the elected presidential administrations they serve: Henry Kissinger)
  • And finally Artist, assuming they have more that 1 hit song, is a more everlasting thing than the Albums they release.

• Case study: DDC
• Compare the following two organizational structures

• • Hierarchical organization
  • Area of study
    • Geographic Region
      • Time period

• • Faceted organization
  • Area of study
  • Region
  • Time period

• The hierarchical structure reflects the way scholarship is generally organized. Very few people study a general time period (1850-1900). Instead, our universities are usually organized by Discipline (ie. Art history, Philosophy, Religion studies, Politics, Physics). Within each discipline, people will choose a particular culture to focus on. Greek philosophy versus East Asian philosophy. And then furthermore, specialists will look at particular time periods. Hygiene in Mongolia during the time of Genghis Khan. * A faceted organization, while more flexible, provides no context for how the facets relate to each other. In other words, the loss of structure is a loss of information about the data.

If structure itself is metadata, how does a data system maintain the flexibility of faceted classification without losing the valuable information that lies within hierarchical structures?

As a result, it's not always clear how best to use Facets

• The lack of a fixed structure also means that users are left to construct the right structure for the right task, which is maybe not what most people are interested in doing. A well designed faceted system should provide users with options based on what they want to accomplish, rather than asking them to construct the right sequence of facets, one facet at a time.
  • If you want to get dressed, the system presents you with the Closet hierarchy
  • If you want to do your laundry the system reorganizes into the Laundry hierarchy

Describing items using facets isn't always the easiest thing to do.

Interaction problem: Facets have to be added one at a time

• Hierarchies provide easy affordances for attaching semantics to data because the entire organizational structure is visualized
• Facets, because they're independent of each other, must be added one at a time (ie. filling out the fields of a form)
• Caeat 1: We believe is primarily a workflow structure and interaction design challenge that can be overcome
• Caveat 2: This obviously doesn't apply to automatically derived metadata (ie. CDDB)
• Hierarchies encode space
  

Cognitive problem: It's hard to design facets well

• Sometimes even the single layer of hierarchy in Faceted systems (organizing Attribute values by Attribute) is too much work
• A well designed facet, just like a well-designed semantically encoded level of hierarchy:
  1. Fills out the spectrum of the facet from end-to-end (ie. Beginning to End: Planning, Execution, Documentation, Post-mortem) so you're never afraid you're missing something.
  2. Has no overlaps, so there's never any ambiguity as to where something belongs.
• Putting this into practice is almost just as hard as designing hierarchies from scratch because it also requires forethought about what might come down the pipe at you in the future
• Katie has a project called 0.6 planning, should she really define it as a Project? or should she separate it into two facets?
  • Release #: 0.6
  • Process Stage: Planning
• Furthermore, is Planning the right granularity?
• Should she split it up even more into different areas of Planning? Ground-up time estimations versus Top-down feature-based planning.
• Are these Process stages? or are they orthogonal to the Planning phase?
• What if finer Process Stages pop-up in the future? Will she bother to re-organize everything according to the new system? Or will some items remain "misfiled" in the older more coarse-grained system?
• This is a lot to consider just to file the first item for 0.6 Planning. Feels like overkill. Feels like something most people wouldn't bother with.