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.
Subject:RE: Planning modular help for software packages From:mlist -at- safenet-inc -dot- com To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Mon, 27 Feb 2006 14:20:10 -0500
Rick Stone [mailto:rstone75 -at- kc -dot- rr -dot- com] suggested:
> 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.
I've tried using that argument. Sometimes it works.
> 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.
We were considering how we could update Help for people
who bought upgrades -- especially since our help is
stand-alone -- and I may be winning the battle to just
give everybody the same help and mark it plainly with
"This function is available if you purchased XYZ enhancement.
Run this command ZZZZZZ to view the current configuration settings".
> 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?
[...]
I argue that it shouldn't hurt, as long as we keep making
it plain that "Some features might not be supported,
depending on the configuration/product version that you purchased."
Just because you _can't_ actually purchase some of those features
during the coming three-month window doesn't really negate that
argument, since most of our customers' purchase/approval cycles
are longer than that anyway.
However, I keep getting flack about that.
For a particular product, its development is being driven by
one big customer, who use a particular subset, but every
other release (or three) we update the other major functional
version as well (FIPS 140-2 level 2 and level 3 versions, if
you wanted to know). Sometimes we're gonna, then it turns out
that we don't have time to test the stuff that the big
customer is not interested in. Rather than stay up all night
removing help I've already written for it (we stopped using
RoboHelp's conditional flags when they bit me on the butt),
I just leave it in now and hope that nobody notices. By the
time the next release rolls around, the testers will be looking
for it, and it'll be appropriate again anyway.
There's some risk, in that this big customer is actually a
VAR, and combines our stuff with another company's product
to present an integrated solution to their end customers...
and those end customer user-types are not nearly as
savvy as either our developers or the big customer's
integrators, so big customer _could_ conceivably receive
some phone calls. However, if they already had, we'd be
the first to hear about it. :-)
Kevin (somewhat skilled at rationalizing what he's gonna do regardless)
The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
