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:rounding up my straying projects From:Berk/Devlin <armadill -at- earthlink -dot- net> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 18 May 2001 00:55:10 -0700
On Thu, 17 May 2001 12:41:28 -0000, the impressively organized "Kim Forbes" <kim_portonova -at- hotmail -dot- com> wrote:
>Ok, I'm working on three main projects. One is going wonderfully. ... The second project was a combined User manual, policy and procedure manual, and training guide. ... project is on hold. ...
>
>The third project, well, how do I start. . . (It is so bad it deserves its
>own paragraph :)) ... I have an unusable program. I told the project manager that I could not document it because it didn't work. (Honest!! It just didn't work....
>
>How do I round up these last two wild children projects of mine?
Kim:
I am not as certain as you are that you cannot document an unusable program.
Obviously, you cannot document an unusable program by RUNNING it and observing how it works. And it's unlikely that you'll want to take screen shots, since these will all change five minutes before the program is finally released anyway. (I, personally, abhor taking screen shots. IMO, screens ought to explain themselves. Guess it's a good thing I don't usually have to deal with GUIs, huh?)
However, I often document programs that are not scheduled to be working for a year or more after I start documenting them. "How is this done?" you ask, shocked, just shocked. Well, you could:
1. Request a spec, read it and document how the program is supposed to work. By doing this, you will also be performing a service for QA. If there is not a spec, you might volunteer to write one and then write the documentation for it, in which case you'd be performing a service for both QA and the programming team.
2. Interview the program designer(s) or the project manager or the programmer(s) and document what you learn. By doing so, you would be performing a service for the programmer(s).
Regardless, the important thing is to have fun.
BTW: I'm mostly responding because I enjoyed reading the sentence "(It is so bad it deserves its own paragraph :))".
--Emily
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Emily Berk ~
On the web at www.armadillosoft.com *** Armadillo Associates, Inc. ~
~ Project management, developer relations and ~
extremely-technical technical documentation that developers find useful.~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by Information Mapping, Inc., a professional services firm
specializing in Knowledge Management and e-content solutions. See http://www.infomap.com or 800-463-6627 for more about our solutions.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
