I received an email yesterday through a listserv that jerked me awake. In a discussion about which is more important when looking for a job, the skills or the tools, one person’s point in particular stood out to me. The respondent said that when you put the emphasis on tools and not skills, you get people who take a class on RoboHelp, for instance, and call themselves online help developers.

She said that she worked with such a person, and among the problems with this person’s products were “topics that require massive scrolling.”

Put me in the lineup, officer.

Okay, so I maybe I haven’t gone to the extent of committing a crime. But this comment directed my attention to a couple of topics in one of my help projects, and I set about fixing the problem immediately.

These two topics consisted of subtasks categorized under one big task. The setup was something like having a topic called “How to Be Hoisted by Your Own Petard” with subtasks such as “How to Find out What the Heck a Petard Is” and “How to Use a Petard.” I had bookmarks and “back to top” links.

But in reality, people don’t want long topics. They want to think that procedures are short and simple. Long topics intimidate people and make them reluctant to consult the documentation in the future. So I broke up my topics and put them in a book whose title is still that original, high-level task. And it contains links to the child topics.

I’m a reformed help author.

Thanks, Sylvia, for getting me to think critically about my own product (and for pointing out that the tools don’t make the professional).

Related entries (auto-generated):

Dropdown Hotspots: A Solution for Cumbersome Help Topics

Write Self-Contained Titles to Preserve Context

Results of a Team Design Review: A Different Context-Sensitive Help Structure

Five Skills for Managing Documentation Projects in an Agile Environment

Well-Phrased Links Help Both Users and Technical Communicators