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: Designing Company Documentation Standards From:Eric Ray <ejray -at- IONET -dot- NET> Date:Wed, 26 Jun 1996 08:46:42 PDT
A few thoughts:
Plan. Plan. Plan. Design an (easy to produce) layout and plan for
online and Web at the same time.
Take your time. Jumping into the documentation without carefully
getting your ducks in a row will cause more problems later.
When I was in a similar situation, I arranged with my boss to
write off the older stuff and not try to get everything caught
up. We moved ahead on new documentation and brought the older
stuff in line as systems were revised and updated.
What I would have done differently?
I should have moved to Framemaker directly, rather than sticking
with the existing (less capable) tools.
Eric
--- On Mon, 24 Jun 1996 15:27:05 +0800 DIGEST Bruce Byfield <byfield -at- direct -dot- ca>
wrote:
> Here's the situation: a company has been doubling in size every few
>months for the last three years. It needs documentation for hardware, software and
>training. However, it has almost none, and what little it has consists of last
>minute efforts done by secretaries working over-time without any idea of layout. So,
>there's a lot of old work to be done from scratch or revised. But the company is
>also launching several new products and services, so there's a lot of new work to be
>done, too. Some of the documentation is internal, some external.
> Can anybody suggest some useful references to help a writer pitched into the
>middle of these circumstances? Obviously, a few documentation standards have to be
>set. But what else? What hints are available about how to assess the situation and
>prioritize? What would make the situation? What are the obvious pitfalls to avoid?
>Is there a book or two which might help?
> And to those who have personally experienced a similar situation, let me
>ask: what advice would you give? Looking back, what should you have done, and
>what shouldn't you have done?
>-------------------------------------
>Bruce Byfield (byfield -at- direct -dot- ca)
>Burnaby, B. C., Canada (604) 421-7189
>Technical Documentation, Demos & Instruction
> TECHWR-L List Information
>To send a message about technical communication to 2500+ list readers,
>E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send administrative commands
> ALL other questions or problems concerning the list
> should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-
-----------------End of Original Message-----------------
******************************************************
Eric J. Ray ejray -at- ionet -dot- net
TECHWR-L Listowner
TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send administrative commands
ALL other questions or problems concerning the list
should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-
