Time for something more than anecdotal evidence, I guess…

Perhaps that’s because if you get one 14-page file that has all the information you need about a limited, targeted subject, you can CTRL+F to search just that page, or use the internal jump links, or scan the headings if you want some quick context.

If the information is broken into four topics that are intermingled with your search results, you have to know the subject well enough already to know you just want to insert or you just want to format. Also you have to know that those two things can be separate steps, so you need to keep scanning the search results to get that context.

Does that make sense to you?

With that out of the way, I wanted to comment a bit and ask some questions.

Trying to replace Google is a mistake (not that I think you’re advocating this appraoch). Content authors are never going to be able to match the massive amount of user generated content available with a quick Google search. Instead, we can rely on the behavior that Google teaches users and do our best to support it. I definitely agree with you there.

In the long tail example, the key ingredient of online stores competing with brick and mortors is location. In this case, the help file is a static chunk of data, like brick and mortor stores. Maybe it should focus on mainstream products/topics? Is it the wrong tool for the task of providing help in the Google age? For one author, trying to cover every niche quickly becomes a Sisyphean task. One person is never going to be able anticipate all the problems that might crop up; in fact, some might not even crop up until after the product ships.

When it comes to niches, there are some topics that receive the majority of traffic, and it’d be foolish to not include these in the help file. But without the data to know which topics those are, how do you pick what to include?

Looking at user forums, Google analytics from online tutorials and other data points are great ideas when you have them available to you. When writing for a 1.0 though, or as a consultant where that data just isn’t there, how do you choose? Throwing as many topics as you can come up with at the wall/user to see what sticks is one way, but it doesn’t feel very efficient. My gut tells me there’s a better way to do it than that.

I’ve always thought the hardest part about writing a help file is figuring out what goes in and what stays out. Maybe if you can manage to get everything in there, the new hardest part is making sure it’s all SEO’d.

And it’s not as if we have Google search algorithms available either. The search available in a CHM file is a bit more primitive. We could easily be overloading users’ intake bandwidth on search results, just as we fear to do in ToCs.

With big products (and after 15 major versions between them, Snagit and Camtasia are very feature rich), it might eventually become impactical to cover all the niches. There’s a real danger of becoming 100 miles wide and 5 seconds deep.

I’m really interested if you had any examples of what niches you thought were missing from the TechSmith help files you looked at (since I’m pretty familiar with those ). I’m also really curious how you’re identifying the niche tasks in your own work.

Great post. It’s really got me thinking about how to provide the help users need and how we assemble and display that information once it has been identified.

or some such, yes?

Interesting thoughts, Tom; thanks for pointing us to Hughes’ original article, too.