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: features gone mad From:Bonni Graham <bonnig -at- IX -dot- NETCOM -dot- COM> Date:Sat, 9 Dec 1995 18:17:20 -0800
>An a la carte approach to software options would get chaotic, fast.
Hoo-ah, yes it does. I once worked for a library automation firm that
had three different families of products. Within each family you could
buy between one and seven modules, in any combination. Documentation
was a nightmare to create and to use.
Some clever programmer had put a front-end menu on the thing at some
point, making the entire system look "unified" -- you could choose a
number from the menu, and not necessarily know you had opened a
different module.
We got ENDLESS support calls from users wanting to know why they
couldn't find something in one of the manuals -- and 95% of the time it
was because they had opened the manual for a different module than the
one they were in. BTW, we did not have online help for this product --
it was a DOS product and online help meant coding.
Had I worlds enough, and time, I could have created a master index --
but then they would have received an index that possibly (probably)
contained many more features than their software had, which would have
been even more calls.
I never really found a satisfactory answer to how to fix this until I
began working on a project for Document Sciences. This new product
(sson to be available from a Document Sciences representative near you!
<g>) allows you to create customized documents for situations like
this. I could have used it to create a single manual for any given
combination of modules, then only printed enough of the things to meet
demand. Three years too late of course.
BTW, I'm not intending to imply that we should *not* modularize
software because the doc is hard to write (although that usually also
makes it hard to use) -- I'm just pointing out a drawback.
Bonni Graham
Manual Labour
bonnig -at- ix -dot- netcom -dot- com
Bonni
