Topic-Based, Hierarchical Navigation [Organizing Content 5]

I mentioned that topic-based, hierarchical navigation, which is the standard for 95% of the help files I see, is becoming a tired, less-than-useful navigation system. We rely on this system too much as technical writers, and it’s not that helpful to users. Here are a few examples to demonstrate this.

I read an intriguing article today called 5 High Paying, Low Stress Jobs on Yahoo Finance. It lists technical writing as the fifth least stressful, high-paying job. I wanted to share the article, so I added it to the Technical Communication Library (TC.Eserver.org).

Without using search, go to Eserver TC Library and browse to the article using the topic-based navigation system. Can you find it?

Now move on to a more difficult challenge. Go to the Yahoo Directory and browse to the Yahoo Finance section (where the article was published). Can you find the site and article?

Let’s try more examples. Suppose you’re learning WordPress, and you want to know what a “widget” is. Using the topic-based navigation (not the search) on the WordPress Codex, can you find the topic that explains widgets?

Now go to the online help in Flare 6 and, using the topic-based navigation, find where it explains how to create image maps.

Let’s say you want to add a caption to a youtube video. Browse the topic-based navigation in Youtube’s help and try to navigate to the topic that explains captions. Bonus points if you find how to create captions in other languages. (Again, don’t use search — we’re evaluating the usefulness of topic-based navigation systems.)

Now go to Chrome’s help and navigate to the topic that explains how to maximize or minimize text and images within the browser.

If you have Snagit, open their help and try to navigate to the topic that explains how to hide your mouse before taking a screen capture.

Try navigating through Audacity’s help on the Floss Manuals site and find how to export your audio file as an MP3 file.

Go to Hulu.com and browse their TV topics navigation to find the TV show Kings. Can you find it (again, without using search or the other, non-topic-based navigation features)?

In any of these examples, did you enjoy trying to guess the technical writer’s logic of organization as you navigated the folders? Sure the logic usually makes sense to the technical writer, because he or she wrestled with the topics and grouped them, probably at great pains, into folders that seemed to make sense.

And perhaps the folders even make sense on a content level as well, that is, the organization is centered on the actual characteristics of the content, not some invention in the writer’s mind.

But even so, most likely this natural order isn’t readily apparent to the new user, who is coming to the material for the first time, without any background or grounding in the same concepts and assumptions and perspectives as the one who organized the content.

As a final blow to topic-based navigation, go to STC.org and find either the bylaws for the association or the latest minutes from the board. Could you find them? Several people told me they’re readily available on the site. But which bucket do you look under? Publications? Membership? Education? Couldn’t the bylaws or minutes fall under any of these containers? It depends what you think the bylaws and minutes contain. It depends how you interpret their purpose and function.

Just because topic-based navigation is often frustrating, as I hope I demonstrated in the examples above, it doesn’t mean we should abandon this system of organization entirely. From a help-authoring perspective, you usually have to group your topics into some containers simply to work with the topics.

But whatever containers we ultimately choose, in the end, if these containers do not exactly match the organizing logic in the user’s mind, the user will take one glance at the help, maybe expand a few folders to peer inside, and then give up. This is why topic-based navigation shouldn’t be the main system of navigation for help content.

Madcap FlareAdobe Robohelp

This entry was posted in findability, general on by .

By Tom Johnson

I'm a technical writer working for The 41st Parameter in San Jose, California. I'm primarily interested in topics related to technical writing, such as visual communication (video tutorials, illustrations), findability (organization, information architecture), API documentation (code examples, programming), and web publishing (web platforms, interactivity) -- pretty much everything related to technical writing. If you're trying to keep up to date about the field of technical communication, subscribe to my blog either by RSS or by email. To learn more about me, see my About page. You can also contact me if you have questions.

41 thoughts on “Topic-Based, Hierarchical Navigation [Organizing Content 5]

  1. Lúcia Garcia

    Now I’m curious to see what and how is the main system of navigation for help content that you suggest.

  2. Eddie VanArsdall

    The organization of content shoudn’t be determined solely by the writer. Users should be included in the development process. Card sorts are great vehicles for engaging users and determining how they view the organizational stucture of the content they use daily.

    1. Tom Johnson

      I agree that card sorting improves organization, but what if all of the examples I mentioned in the post were developed after card-sorting exercises? What if the card sort yields discrepancy and only highlights the problematic nature of topic containers?

      1. Eddie VanArsdall

        Then do more follow-up testing with users, examine problem reports from those who are actively searching the site, and make improvements accordingly. My team does that daily.

  3. Ted Kuster

    I think we’re kidding ourselves if we think TOC structure matters much to anyone besides us. The large majority of my users come in via searches and links; I think that’s true for almost everyone these days. (Everyone whose content is web-accessible, I mean.)
    The reason I still put effort into devising and maintaining a TOC structure is that it helps me and my team manage big piles of information in something like a rational way. That certainly helps the user, but only indirectly. And of course we still put our TOC out there in the left pane, for those few users who like to read that way, but if the tools didn’t make that easy, I doubt that we would bother.

    1. Tom Johnson

      Thanks for joining in the conversation, Ted. I agree that grouping topics into some sense of order is helpful even it it’s just for the tech pubs team alone.

  4. Techquestioner

    Your examples definitively show that TOC topic-based organization does not meet the needs of users in many situations or web-based products. I’m interested in learning more about other organization options.

  5. Bill Kerschbaum

    Tom, good thoughts. You’ve helped me see the quandary very clearly. So what do you suggest? I’ve seen word maps or mind maps, in which words or concepts are connected to each other like a spider web. I haven’t seen a help system anything like that, though – but it might be interesting to explore.

  6. Jen Dick

    This is an issue that my organization is struggling with at the moment. We have a professional social network that includes a lot of media, files, and other resources. Everything is buried in the current topic-based hierarchical structure. Our users can’t find anything.

    While I don’t think we can totally abandon hierarchy, I’m curious to investigate what a purpose/task-based re-org of our site would look like: focus on why the users logged on in the first place–are they looking for a video? Wanting to pose a question to a discussion group? Get information on a topic?

    I’m also very interested to hear what other people have to say on alternate methods of organization. Thank you for an awesome article series!

    1. Tom Johnson

      Jen, glad to hear your voice here. I’m going to explore some other methods of organization. This topic isn’t just a problem for technical writers organizing help. It’s a problem for websites, search engines, intranets, and every other information-heavy space.

  7. Derek Warren

    Great discussion going here.

    So content organization gets reflected in the master TOC, but it’s only one method of navigation in most help systems. In my thinking, these are the tools of navigation and the users who are most likely to benefit from them (ordered by most useful to least useful):

    1. Context-Sensitive Help liks: Properly implemented, most users won’t skip a visible help button in search of the TOC; takes the user directly to a related topic, which in turn broadens the scope (via related topics/see also links); unfortunately, these are often either not implemented where and when users need them, or not implemented at all

    2. Search: Useful for all users, assuming an effective search engine; the better the search results, the more successful the user; also, the most common method of online navigation

    3. Index: Useful for all users, assuming expert indexing; users aren’t necessarily required to know the lingo when effective indexes attempt to use more common terms to lead readers to relative info

    4. TOC: Useful for users who are already familiar with the subject matter; they’re comfortable with the terminology of the product; they’re comfortable with the feature priorities of the product and where the help reflects this logic, they are more likely to feel right at home (and yet, even these users are more likely to use search first because of the perception [reality] that it is faster)

    (It would be interesting to see these charted on a graph based on real-world data…probably has been done more than once, so please share if you know of such research.)

    Interestingly, at the Writer’s UA conference in Seattle in April, a live survey was conducted during the opening session. When asked how important a table of contents is to online content, 32% said “Moderate value”, while only 25% said “Indispensable”.

    1. Tom Johnson

      Cool. I didn’t know about that survey until you mentioned it here and sent me the info. That will be helpful as we continue forward with this topic.

      The other methods you list here are good ones. Thanks for brainstorming ideas along these lines. I think the index is necessary but problematic, for reasons I’ll explain later.

  8. Derek Warren

    A few additional thoughts on Search…

    Seems to me that today’s expectations for Google-like search functionality (everybody’s doing it!) makes the TOC/content structure almost irrelevant. This of course assumes a fabulous search engine, which WebHelp (and most flavors of help) don’t employ. But there are ways around that, depending on how exposed your content can be on the Web.

    So it seems to me that effective searches render the TOC rather irrelevant (exception: at the point where a user clicks a search result and the TOC synchronizes with the topic in view to instantly reveal the context of the topic within the broader structure).

    1. Tom Johnson

      I agree about the tools. The way Search works in most HATs is the same way it worked 15 years ago, while many websites now have predictive search, faceted search, and other more advanced search features. I can’t even move the search box in my help files. I also can’t limit the returns, or specify where the returns appear. I can barely find out information about the way the search works.

    2. Donna Spencer

      Search is fantastic all the time people have terminology and know how to spell it. But for all the times they don’t – particularly they are looking for something for which they don’t know the answer (so don’t know what to call it) search isn’t very useful. That’s when good navigation is critical (indexes are no better than search) and clearly-labelled buckets are the key.

      1. Tom Johnson

        Donna, I was just listening to your IA Summit talk on information architecture! I didn’t realize that you had commented on my blog. How cool. By the way, I really enjoyed your presentation on information architecture patterns. It’s opening up so many doors to me. In fact, the whole concept of “patterns,” whether search patterns, wiki patterns, information architecture patterns, or design patterns, is cool to know about. As far as I know, there isn’t a body of research about “help patterns,” but there should be.

        Anyway, I’m hoping you can shed light on my existing attempt to apply faceted classification and search to help content. Do you think it’s a pattern that fits well? I am having trouble coming up with non-topic-based facets to describe help content. So I’m not sure if it’s a pattern that fits.

        What is common with help content is to supply tables of contents, indexes, “See Also” links, glossaries, and cross references. But these navigational aids seem dated and overall don’t solve the problem of findability with help content.

        1. Donna Spencer

          Hey Tom

          I think that in theory faceted browse could apply to help content, but in practice you are unlikely to find enough facets to make it a good approach (and readers may not have three things they want to narrow the content down).

          Truly, this is a normal information architecture problem. A hierarchy, done well, is not a bad approach (*done well* is the trick) with A-Z, search to support it. But think about the ‘focused entry points’ pattern as well, where you provide entry points for particular audiences or tasks (getting started, audience groups etc).

          I’m not believing the core premise of your argument, that there is a problem with normal navigation aids and findability. I’ve worked with help done badly (MYOB!!!) and help done well. Help done well understands what people want to do, help done badly describes everything from the system perspective.

          1. Tom Johnson

            Donna, thanks for your response. I wish there were more specific analyses of help content by information architects. When I was reading up on faceted classification, almost every example involved websites selling merchandise of some kind rather than information products.

            I like the idea of “focused entry points,” and it’s okay if you reject my core premise. But in the help field, we routinely hear about the uselessness of help. Users call asking questions that are “clearly” found in the help. When users have a specific question, using navigation instead of search often fails.

            At the very least, I wanted to explore other ways to organize the content besides the traditional topic-based hierarchy. I do realize that user ethnography and cart sorting would go a long way to improving the terminology and navigation of the help content.

  9. Derek Warren

    And yet a few more thoughts…on Indexes…

    And what about indexing? Seems like search has all but killed the notion of an index. And yet the index is another tried and true tool (when thoroughly implemented) that can help a user to find her way around the whole content organization dilemma.

    In one way, a good index is much like a keyword cheat sheet. When used in conjunction with full-text search, it can also improve search results.

    1. Tom Johnson

      Here’s the problem with indexes. First, users don’t like them. Even as far back as 1996, only a small number of users see indexes as valuable information retrieval tools (I have a TC Journal article to reference there).

      Indexes are valuable in that they allow you to add keywords to your topics, which improves the search. But the way people search is not the same way people browse a list of index words. Because Flare uses an exact-match search algorithm, giving most priority to exact matches, the index ends up being a metakeyword tool that doesn’t function as a traditional index anymore.

  10. Derek Warren

    And a final, parting shot on content organization… ( how to create > edit > delete), then browsing the structure becomes easier for users who know something about the subject matter. It probably will not help users who are new to the subject matter.

  11. Paul K. Sholar

    Users in a hurry want to take shortcuts. But sometimes there ain’t a shortcut, especially when the user doesn’t really understand the application yet. It might sound good to offer alternate tag hierarchies, but this means the writer is still trying to outguess the clueless.

  12. Paul K. Sholar

    I offer that most of these concerns come down to the conceptual design of the application. If the “mental model” required of the user is a little too far away from what the user already knows, the application provider is risking push-back from users who don’t want to spend the time absorbing too many new-fangled notions. Another issue is the fact that too many applications have too many features, such that once again the technology companies come to expect “heroic” measures from the TWs in organizing the content and out-guessing time-stressed users.

  13. Paul K. Sholar

    “Suppose you’re learning WordPress, and you want to know what a “widget” is.”

    Why not support a search among topic headings versus topic bodies? If the text is found in a topic heading, return the heading and the “local” part of the hierarchy of topics that the found heading is “among”.

  14. Geoff Sauer

    I like your thoughtful investigation here, Tom, but I’m not convinced that we can draw useful conclusions from these tasks.

    After Rosenfeld and Morville’s 1998 book _Information Architecture for the World Wide Web, the field began to differentiate between two discrete behaviors — “browse” and “search.” People who browse the EServer TC Library’s Careers>Technical Writing section are behaving differently and have different goals than people searching for a particular article.

    In your prompts, you’re asking people to perform a search function, and then only use interfaces designed to facilitate browsing behavior. You specifically asking them *not* to use search tools while searching. Then you ask them to draw conclusions from their experiences that this doesn’t work well.

    It may be that in a modern age of users who trust and love search behaviors (a problem of its own we should address), people don’t use “old-fashioned” browse indexing as much as they used to.

    But I’m not sure what strong conclusions we can draw from that?

    1. Tom Johnson

      Geoff, you bring a new perspective to this discussion. Thank you. From what I gather, esp. after reading this article, one browses a TOC when he or she is looking around at what’s there, usually moving with a mind open to discover new things. In contrast, a searcher is intent on locating a specific piece of information. Is this the distinction between browsing versus searching behavior that is elaborated upon in the Information Architecture book you referenced?

      If so, I can see how my exercises to have users search for an item by using a navigation system set up for browsing will cause “information retrieval failure.” I do think that many help authors still create topic-based nav systems with the idea that users will look in them to find topics, not necessary to browse the information. But now you’ve opened up my perspective to the real value of the topic-based table of contents.

    2. Tom Johnson

      I was actually listening to an IA Summit Talk by Peter Morville in which he mentioned the limits of search. When users search for information, they don’t usually discover the “unknown unknowns.” Searchers limit themselves from finding new information because they’re just looking for topics or information that they already know something about. Hence there needs to be a mechanism for surfacing what the user does not know. Here the topic-based TOC works nicely. By the way, all the IA Summit 2010 talks are on the Boxes and Arrows podcast in iTunes for free.

  15. Geoff Sauer

    Hi Tom,

    Yes, that’s what I mean, exactly. Browsers tend to be more leisurely, looking to “read to learn” (to use Ginny Redish’s phrase). Searchers are often being more direct, looking to “read to do” or “read to learn to do” — a somewhat different goal.

    One learns the proper keywords for searching by browsing, reading within a discipline. Traditionally, people would use both of these behaviors to inform each other. So traditional books were organized with features for each sort of behavior (a table of contents and an index, for example, for browsing and searching sorts of behavior).

    We gain a great deal when we realize that modern users most often access our online materials with a “search” behavior. It’s worth rethinking why we spend as much time as we do devising affordances to facilitate “browse” behavior. But I think we might be wise to continue to plan for both sorts of behaviors. I, myself, think the present dominance of “search” behaviors is a bit of a fad right now, and that “browse” will reemerge once people start to recognize the things we miss with search. :)

    But I love that you’re facilitating this discussion, and look forward to seeing other comments and your next posts on this.

    1. Tom Johnson

      Geoff, thanks for your comments here. It does seem that many people, especially technical writers, assume that users will turn to the default mode of search when looking for content. I’ve heard in numerous presentations and papers that we are in a Google world, where we find information by searching. And yet, some web usability people say that only about 5% of people actually use the search feature on a website. People may use Google to get to your website, but then they often use the navigational features on your site (rather than a site search) to find information within it.

      The problem with web usability research (such as the link I referenced above) is that it most likely refers to regular websites, not help content. So it’s hard to know just what user behavior is with help. Are you aware of any research that has been done about the degree to which users search help content rather than browse it? It seems like such a fundamental thing to know, and yet I’m not finding anything.

  16. rapidok

    I agree with the author, original topic-based navigation systems should change and involve more flexibility in them to enhance the user experience. I really liked your example about trying to search for “widget” in the wordpress codex ) thanks for posting anyway and keep it up.

  17. naxsoanda

    [MARKED AS SPAM BY ANTISPAM BEE | CSS Hack]
    Hello, Drug Facs buying phentermine online However, if you do feel that you are suffering with any of these side effects and you are worried about it then it is definitely a good idea to consult with your doctor so that they can reassess your situation and decide on the best plan of action for you in terms of medication. http://www.embrepair.com/ – purchase phentermine

  18. Pingback: Faceted Classification, Faceted Search [Organizing Content 6] | I'd Rather Be Writing

Comments are closed.