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: Minimalism: Opportunity or Menace? (long) From:"Susan W. Gallagher" <sgallagher -at- EXPERSOFT -dot- COM> Date:Thu, 23 Jan 1997 12:15:03 -0800
At 01:13 PM 1/23/97 -0500, Steven Jong wrote:
>As a structured documentation disciple, I think I understand minimalism. In
>fact, I believe I am a minimalist at heart. [snip]
>At Digital one ambitious young doc supervisor caused the rest of us no end of
>trouble [snip] upper management siezed
>on the 'cut-by-half' idea and decreed that all our doc sets would be cut by
>half. This hurt particularly in areas where careful, minimalist writing had
>already occurred. Have you observed similarly pointy-haired decrees?
Oh, the siren song of lower page counts, the allure of lower cost to
market! ;-) A little knowledge is often a dangerous thing. Upper
management certainly can't be blamed for being drawn to that particular
flame. It's up to those of us who manage the doc process to be stalwart
in our defense of user needs. Shame on your doc supervisor for using
the results of a successful doc project for personal gains to the
detriment of the rest of the team.
>Microsoft's documentation is clearly a highly visible example, but of what? A
>92-page operating system user's guide is breathtaking; is that *all* of it?
The folks at Microsoft had their own problems to solve, and, IMO, they did
an admirable job under the circumstances. Their mission was to provide the
most needed information to the majority of users using as little disk
space and paper as possible and they did it. But their mission in providing
an operating system solution to the masses is not necessarily our mission
in providing application software to a more restricted market. When folks
look at the documentation from MS, they see Win 95 online help. They don't
see the MS Developer Network, in which a torrent of information is provided
by subscription. MS can, when necessary, tell you everything you need to
know. They just have to believe it's necessary and you have to believe it's
worth the money. ;-)
>You can turn a hundred gallons of maple sap into a gallon of maple syrup, but
>not by extraction; the process, boiling, is long and slow. Though I believe
>in the minimalist writing process, I worry about having the results
>arbitrarily imposed: "Thou shalt write no more than 50 pages per book." What
>do you think?
Any documentation solution, including whether to use a minimalist approach,
a modular approach, info mapping, etc., depends on the product and the
target audience. It relies on the expertise of the documentation staff to
evaluate the needs and devise the optimal solution. Any arbitrary restrictions
imposed by non-documentation staff on the documentation process will result
in a less than ideal doc solution.
While I certainly understand the goal of reduced page count and the guidelines
imposed by a minimalist approach, I believe that each documentation project
demands its own solution. Not every miminalist-style manual is small, y'know!
I would make it clear to management that you will make every effort to
achieve their goals for lower page counts in so far as it can be done without
compromising product quality and usefulness.
When others point to Win 95 online help, explain the difference between
providing an OS to an enormous horizontal marketplace and providing
application software to a small vertical market.
When others mumble about lower page counts, recite the minimalist mantra...
* Get users doing meaningful tasks quickly
* Document a single way to perform a task
* Encourage exploration and error recovery
...and explain that minimalist documentation doesn't always result in smaller
Whew! Guess I got a little carried away! Sorry for being so long-winded!
Hope I've given you some useful ammunition. Good Luck!
Susan W. Gallagher Manager, Technical Publications
sgallagher -at- expersoft -dot- com Expersoft Corporation, San Diego CA http://www.expersoft.com