---
title: "Can Help Content Have Recognizable Facets?"
date: 2013-05-29
description: "$( document ).ready(function() { // Handler for .ready() called. $("
canonical_url: https://idratherbewriting.com/2013/05/29/can-help-content-have-recognizable-facets/
---
# Can Help Content Have Recognizable Facets?
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"):

![Faceted search on Linkedin](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/facetedlinkedin.png)

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](http://help.linkedin.com/app/home) 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](https://drupal.org/project/apachesolr) (made easy through the [Acquia Search](https://drupal.org/project/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](http://everypageispageone.com/2013/03/25/readers-dont-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](https://docs.palantir.com/gotham/3.11.1.0/wwhelp/wwhimpl/js/html/wwhelp.htm), 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](https://en.wikipedia.org/wiki/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.

![The massive TOC"](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/organizing_contentv2_8-600x370.png)

 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](https://idratherbewriting.com/2010/06/03/from-help-authoring-tools-to-web-tools-especially-wikis-organizing-content-12/).)

## 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](http://dir.yahoo.com/computers_and_internet/internet/) 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.