TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
I tend to side with Paul on the bit about supplying all the help. Here's
why.
I once worked as a lone tech writer for a small software company. The
company sold its software in a modular fashion as well. I think there were
about 15 modules that could be combined in any number of ways. It simply
depended on which modules the customer wanted to buy. Upon discussing the
help system approach with one of the owners of the company, I explained that
we could make the help modular. He immediately shot it down for the
following reasons that made perfect sense.
1. If the customer has access to all the help, actually seeing the help for
the modules that aren't present might work as a sales tool to entice them to
purchase the missing modules.
2. Maintaining help without concern for who has which modules installed will
be easier for all involved. For me as the tech writer, I didn't have to
devise paths and links to accommodate the potential missing modules. For the
gentleman creating the installation package. He didn't have to determine
which help modules to install depending on the purchased products. We all
win.
3. Think about this one. Does it really hurt the product at all to have help
available for something the user would not be able to do? For example, I was
also in an environment (large call center) that had your basic level techs
answering phone calls. What they couldn't resolve was escalated to the
"senior" or "second tier" techs. The "senior" techs wanted their own special
help file that contained the entries that they could use to override things.
The kicker here is that they wanted this help "hidden from view" unless you
were a member of the super secret and ultra powerful second tier support
group. But really, unless you were part of this group, you didn't have the
authority in the system to make these entries anyway. So what does it really
hurt to make them available to all? If you can't make the entry, the
information is useless anyway. Doesn't offer up a "back door" into the
system or anything. ;)
Just thoughts... Rick :)
----- Original Message -----
From: "Paul Hanson" <PHanson -at- Quintrex -dot- com>
To: <techwr-l -at- lists -dot- techwr-l -dot- com>
Sent: Friday, February 24, 2006 10:36 AM
Subject: RE: Planning modular help for software packages
You have a lot of work ahead of you and I wish the best of luck in
figuring
it all out. One of the things that threw up a red flag in my mind is to
bring up the situation where your documentation already has link(s) to the
doc for a package the client may not have installed. For example, if your
client only has Packages A & B, but you have a link from B to C in the
doc,
you either have to not give them the information in package C by rewriting
the content to not refer to package B <which if that connection exists,
that
makes your doc incomplete> or give them the doc for package C. I document
a
system that has many of these cross-system links
<http://www.quintrex.com/Products/Grid_prod3_small.htm> so I don't think I
could do what you are suggesting. I give our clients all the doc.
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!. http://www.webworks.com/techwr-l
Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at http://www.componentone.com/TECHWRL/DocToHelp2005
