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.
Re: Striving To Increase The Page Count Was: Estimation of the number of pages...
Subject:Re: Striving To Increase The Page Count Was: Estimation of the number of pages... From:David Neeley <dbneeley -at- gmail -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Mon, 3 Jan 2005 19:51:19 -0600
Tony,
In the shops in which I have been, you would not *last* three weeks if
the result constituted "nine smaller size paragraphs." Few people
today have that kind of leisure or budget.
On the other hand, measuring productivity by page count or by some
mechanical topic count seems rather foolish. Ultimately, the question
that should truly count is whether given the time and resources at
your disposal you created the most useful document for the intended
audience. Too often, we have a bulk of software documentation
consisting of a mechanistic features list working from menu to menu in
the interface.
Ideally, given time and the authority to do so, user documentation
should be fluid--being updated as needed to respond to real-world
questions and problems among users in the field. Given the ability to
have documentation downloadable, this is increasingly possible. That
is why the docs people responsible for a given product doc set should
be monitoring the tech support issues continuously throughout the
product lifecycle...with recurring problems being earmarked either for
the next upgrade or for a slipstream documentation upgrade if
sufficiently serious. Again ideally, though, these recurring problems
should result in a design review involving the usability of the
product and not simply a docs change.
Still, for budget and time planning purposes, it is necessary to
attempt to come up with these forecasts. Again ideally, writers should
be rewarded for appropriate brevity and the accessibility and
usefulness of their output IMHO.
To be reasonably accurate in making this forecast, it may well be that
specific classes could in fact be extremely helpful. I know in my own
case, this is something I need to pay more attention to as part of my
ongoing attempts to improve.
Personally, I believe that documentation is often much too long
because of a lack of time to edit properly...sort of an "I apologize
for the length of this letter, for I did not have time to make it
short" sort of thing (variously attributed).
In fact, I have rarely been part of a doc project that had sufficient
time that there was little rush at the end of the release cycle.
Usually, it's a mad scramble to get everything covered that absolutely
must be included, let alone the time to edit and polish. Perhaps your
experience has been different?
ROBOHELP X5 - SEE THE ALL NEW ROBOHELP X5 IN ACTION!
RoboHelp X5 is a giant leap forward in Help authoring technology, featuring all new Word 2003 support, Content Management, Multi-Author support, PDF and XML support and much more! View an online demo: http://www.macromedia.com/go/techwrldemo
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
