Can Help Content Have Recognizable Facets?

by Tom Johnson on May 29, 2013
categories: findability

In my previous post, I wrote about faceted search and faceted classification, and how facets can help users narrow information to a specific topic.

Even if you've never heard the term "faceted search," you've no doubt used it on various websites, like Google, Amazon, Linkedin, and more. When you perform a search, you get a list of filters to further narrow the information. Each of the filters (or facets) narrows the results. Here's faceted search on Linkedin (after searching for "technical writer"):

You can narrow the results by company, relationship, location, date, salary, industry, experience level, and more. The facets that appear depend on the type of information you're looking for -- companies, jobs, people, and so on.

Faceted search works great because you can start out with broad search terms and progressively narrow the information. If you narrow too quickly, you can easily de-select some of your filters and expand the results -- without having to create a new search.

While we see a lot of examples of faceted classification on the web with regular websites, which often have products with clearly distinguishable features such as size, weight, color, make, model, brand, mileage, and so forth, help information is more nuanced. Help topics are mostly just information. Additionally, we have almost no examples of faceted search in help systems as a foundation to examine. Even Linkedin's help center doesn't have facets.

Where Are the Examples of Faceted Search?

The lack of examples of faceted search in help systems doesn't mean faceted search wouldn't be a great feature to add to a help system. One reason we may not see faceted search in help sites is because many tech writers use help authoring tools that do not provide this capability out of the box. And companies don't usually dedicate programming resources to create custom solutions for the tech pubs group.

A few years ago I attended an STC Summit and asked as many knowledgeable people as I could about how to implement faceted search. Not one person could tell me how to do it. The only answer was that I'd probably have to build it myself through a team of programmers.

Well, tech has advanced since then, and now with the Apache Solr Search (made easy through the Acquia Search) on Drupal, you can get faceted search up and running in a short amount of time without programming anything yourself. (In another post I'll explain how to set this up on Drupal.)

But now that the technical question is partially resolved, we come to a difficult strategic question: What facets do you use with help, since help doesn't have clear physical attributes to call out?

Do Users Navigate Through Classifications?

Before turning to possible answers about help facets, let's question our assumptions. Do facets, which are really classifications (or groupings), serve as useful guides to help people find information?

I'm going to dig deep into the challenges to classification for a while, but I promise I'll swing back around to facets. Stick with me because the challenge to classification is fascinating as well as fundamental to accepting facets.

In Readers Don't Classify Their Experience, Mark Baker argues that a hierarchical navigation (such as with TOCs) doesn't work with large-scale content because large-scale TOCs create meaningless high-level classifications. The classification schemes authors invent to make sense of their content mean little to readers. Mark writes,

The reason it does not work is that people do not classify their experience. They do not say, “I have an ache in my second upper bicuspid,” they say, “I have a toothache.”

In other words, users don't start out by navigating through some arcane dental anatomy (Alveolar Processes > Mandibula > Biting and Chewing > Bicuspids > Upper Biscupids > Toothaches). They search directly for their problem: toothache.

If you look at one large doc set from a company like Palantir, you can see the attempt to group large-scale content into high-level folders. Do "Applications," "Administration," and "Customization" mean a whole lot to users? Probably not. The user doesn't think, I need to set up my widget, so I'll look in Administration and then filter through the folders (e.g., Maintenance > Tracking > Configuring ... ) from there.

Of course, since I'm not a user of Palantir's products, I really can't evaluate their help. So I'll turn to something more tangible: Wikipedia.

Wikipedia's groupings provide an even stronger case about the absurdity of adding hierarchical navigation for large-scale content. If you were to organize Wikipedia into a TOC, here's how you would navigate to find "Technical Communication."

Articles
  Main topic classifications
    Life
      Society
        Sociology
          Culture
            Humanities
              Language
                Writing
                  Written Communication
                    Technical Communication

I'm not making this up. Start at the Technical Communication article and scroll to the bottom, looking for the category. Try to trace your way up. Every category must be contained inside a parent category -- those are the rules of Mediawiki (the wiki platform for Wikipedia).

There's a bit of suspense in climbing up the navigation hierarchy. As I'm going up I think I might end up at the core fundamental Truth and origin of the universe, but it just turns out to be "articles."

Why is there no TOC in Wikipedia? Because if they ever converted their category hierarchies into a table of contents, it would be such a joke that people would be checking their calendars to see if was April 1.

This kind of meaningless hierarchy is exactly what we technical writers do when we create a massive TOC. Even limiting the hierarchy to four levels leads us to a meaningless group on Wikipedia: Language. Who can anticipate that the starting point in trying to drill into "technical communication" would be language? I can think of a dozen other paths that would make just as much sense: Communication, Technology, Computers, Careers, User Experience, Instructional Writing, and so on.

Authors sometimes resort to building a single massive TOC for all content. The problem with large-scale TOCs is that they force authors to nest content into so many hierarchical levels that the high-level groupings become abstract and meaningless to users. Both hierarchies here might provide equally logical paths to the same end.

(By the way, I previously wrote about Wikipedia's category structure in From Help Authoring Tools to Web Tools, Especially Wikis.)

Does The Failure of Large-Scale TOCs Mean Classification Is Useless?

There's probably not a more intuitive way to logically classify large-scale content into different groups. Yahoo's Internet Directory proved the failure of navigation hierarchies long ago.

However, once you drill into the right folder, the small list of topics in a specific folder makes more sense and is meaningful to users. At the micro-level, a list of topics sort of works, and one or two hierarchies can establish meaning and context.

Mark concedes the utility of small navigation lists:

... a small scale TOC acts as a list that the reader can simply browse, but a large scale one becomes a classification scheme that users have to navigate. If you can't take the TOC in at a glance, or at least read it through comfortably, then you have to trace down particular paths in the hierarchy of the TOC, and that means you have to figure out the classification scheme behind the TOC. And that does not work. (Readers Don't Classify Their Experience)

In other words, reinterpreting Mark's implicit point, a small-scale TOC that the user can simply browse, taking it in at a glance and reading through comfortably, works.

The problem is, if all your navigation paths are just two levels deep, you'll end up with dozens of navigation options -- each really shallow. Users aren't accustomed to browsing 45 different navigation folders as they try to determine which folder contains the information they want. So classification of large-scale content fails even when you flatten it out.



Before you throw classification out the window and force all users to search for content, remember that time and space in digital mediums do not constrain us with the same limitations as paper mediums. You can have both a large-scale and small-scale TOC on the same platform with the same content.

Facets to the Rescue

Search facets can help balance large-scale navigation with small-scale results. This is because facets only appear if the tag exists within the search results.

For example, you might have 15 different vocabularies in your taxonomy, each with their own terms. Maybe you have 150 different total terms on your site. It would be too overwhelming to list all 15 folders with their 10 terms as a navigation. It would be the massive TOC that fails to communicate meaning to the user because you have so many nested hierarchies trapped in layers of abstract, high-level classification.

But that's not what happens with search facets. Facets hide the large-scale TOC from the user. When a user searches for "widgets," the user doesn't see all 15 navigation options, each with a full array of terms. Instead, the user sees only the relevant navigation options. A search for widgets might pull up 5 vocabulary sets, and only show 8 terms from each vocabulary.

In this way, faceted search does a brilliant job in balancing out search with navigation. It makes it possible for users to browse because it limits the TOC to a small-scale -- you get 20 navigation options instead of 150. And it also makes each of these browsing options extremely relevant. Every folder already shows possible results that have some keyword relevance.

In short, faceted search makes browsing meaningful and practical. Browsing the entire set of information doesn't work, but browsing the micro-set does. You start with search, and then you get a meaningful result set to browse. Users can select filters to execute more specific searches on the fly, or clear those filters to expand results on the fly. Here we have browse and search working together like a fully unified couple, each contributing to the success of the relationship.

Moving on to More Practical Matters

Now let's move on to more practical matters. Which facets work for help?

In another post by Mark Baker, Sometimes Readers Do Classify Their Experience, Mark argues that faceted search only works when the facets are familiar to users as common ways to group the items.

If you look at car sites like autocatch.com (which use facets like mileage, year, make) or medical sites like WebMD symptoms checker (which use facets like body part, type of pain, duration, etc.) you'll feel the facets are a natural fit because you're accustomed to dealing with those topics through that facet language.

But since help doesn't tend to have familiar facets, coming up with meaningful facets is more challenging.

Our tendency from ecommerce sites is to look for physical attributes like size, color, and shape. But maybe that sells facets short. I've been reading The Discipline of Organizing, edited by Robert Glushko (published May 2013). Robert writes,

Unlike those for physical resources, the most useful organizing properties for information resources are those based on their content and meaning, and these are not directly apparent when you look at a book or document. (p.15)

I'm only 50 pages into the book, so I have a lot more to read, but already the book has catalyzed some thoughts about facets. If the "most useful organizing properties for information" are "content and meaning," not physical attributes like size, color, and shape, then perhaps some worthwhile facets can be leveraged for information-based content.

In my help information, I have the following groups of information that revolve around content and meaning:

• Game components (such as points, leaderboards, behaviors)
• Development tools (such as API platforms and SDKs)
• 3rd party integrations (such as with WordPress, Ensighten, or Jive)
• Reports (analytics about program activity)
• Program Frameworks (competitive frameworks, social loyalty frameworks, and so on)
• Timeline (introductory phase, pre-implementation)
• User type (marketer, developer)
• Content type (forum, blog, documentation)
• Article format (PDF, video, quick start, API reference)

Facets that involve content and meaning are specific to the information and domain. Facets that are more useful might be the following:

• Date published
• Popular content
• Author (this is questionable)

It's probably not useful to have too many facets. Five or six is more practical. However, as I mentioned previously, you could come up with 12 or more facets without overwhelming the reader, because the facets only appear if search results include those tags. It's unlikely that the search results would include all facets every time, so your navigation options shrink to the micro-level for most searches.

I'm still experimenting with faceted search, so I can't share more experiences here. It's true we have a dearth of help examples that incorporate faceted search, but I'm sure that as faceted search tools become more common, tech writers will leverage them for the benefit of users.

In upcoming posts, I'll explore faceted search with more depth. If you've implement faceted search in your help, I'd love to hear about your experiences.