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.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.