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: Documenting A Moving Target From:beth_staats -at- ARTISOFT -dot- COM Date:Wed, 21 Feb 1996 13:11:42 MTN
[<snip:> I am trying to document a product that
is still being developed, not just tweaked.]
-----------------------------------------
This was a big problem with the last software product my company produced on an
all-time record-short deadline. It is always a problem (as everyone else has
stated) but it was worst of all most recently.
I had to document a very complicated piece of that software. It was a tangled
web of many interrelated windows. In an effort to figure it all out, I wound up
doing an Alt+Print screen of each window, pasting them into a Word doc,
printing it out, then cutting out the windows and taping them to my cubie wall
with arrows showing the flow. Seeing it all together even helped the
developers; one saw it and said "there's TOO MANY windows."
I had no time to keep reprinting the screen shots every day (that's how often
changes occurred) but when the project was over, I suggested that next time, we
assign the Engineering Dept. admin. person to assemble a complete storyboard of
all screen shots in the program, and reshoot them and paste the updates on the
board them every time they change. This would leave it up to her to hassle the
developers about changes in the GUI interface. That would make it easier on
them, as they'd have only one person asking, and they might even get so used to
it they'd come to her and tell her. She should make notes on the printouts as to
the date captured, and the initials of the developer in charge of that section
(who to bug). She could circle the part of the window that changed. We could
swing by and look for new dates.
If she scotch-taped the new windows right on top of the old ones, this would
also provide Engineering with a complete history of the development cycle, which
might be enlightening.
I realize that capturing the interface doesn't necessarily show all the
functional changes, so we writers would still have to have regular meetings with
the engineers.
All the other suggestions that people have put forth on this topic are good! I
just thought I'd throw in another one that might help.
