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: Why We Need Good Software Manuals From:SANDRA CHARKER <scharker -at- OZEMAIL -dot- COM -dot- AU> Date:Fri, 26 Jan 1996 22:54:57 +1000
Charles Good (good -at- aur -dot- alcatel -dot- com) wrote:
<snip...
> I've even seen a couple
> of very large companies form their own documentation groups to produce
> paper documentation for products that do not meet their standards.
...end snip>
And I think *that* is a pointer to the future of software documentation.
IMO, much of the expense and effort that now goes into documenting software
packages is wasted. And as the packages get more tailorable, flexible, and
feature-rich, the documents can only become more compromised and further from
the needs of end users.
Other pointers:
* The wildly different opinions on this list about the docs for the packages
we use.
* The growth of workflow tools, electronic performance support systems, and
interactive manuals, all of which make best sense when they are specific to the
sites and environments in which the are used.
* 6 years puzzling over how to write sensible tutorials (paper based) for an
accounting and warehousing package in which everything the users (mostly
clerical, phone order takes, and warehouse staff) could see was tailorable.
* 6 years (the same 6 years) writing reference manuals for a strongly modular
accounting and warehousing package (the same package) for which users
(different users, mostly financial controllers, warehouse managers, and
marketing managers) could control when and how far they integrated the modules.
* Realising at the end of those 6 years that the only people who really used
(and who LOVE) my cherished tutorials and manuals are the value-added
resellers. They get paid by the user-sites to write in-house training based on
our tutorials, and they keep telling us that the reference manuals are have all
the information they need to tailor the package. That was nice to hear, but I
don't think it justified the cost of those manuals to the company that produced
the software.
* A report this week that "216 of Australia's leading companies" expect that
in 5 years more than 60% of their software will be packages that have been
tailored for them by system integrators and contractors.
Seems to me that site-oriented documentation is the natural next step after
task-oriented documentation. Documenting software packages is just
function-oriented documentation on a larger scale.
Of course, not all software packages can or should be documented in the same
way, so I'm overstating my case a bit. But probably less than I think.
Sandra Charker
scharker -at- ozemail -dot- com -dot- au In spectacular summertime Sydney,
208 years old today, and still gorgeous
