Changing Tires at 60kph/Reprise (long)

Subject: Changing Tires at 60kph/Reprise (long)
From: "Dennis Hays/The Burden Lake Group, Ltd." <dlhays -at- IX -dot- NETCOM -dot- COM>
Date: Wed, 6 Mar 1996 21:50:50 -0500

For those of you late coming in to the audience, I'm doing a sporadic
journal on my current contract for the US Department of Energy--a government
(Euuuuuu!) project.

Welcome to the next chapter of "Wordless and Be-Saddled" or "The Further
Exploits of TechWriter Man in the Halls of Horror."

When we last left our intrepid hero, he was busy rewriting Chapter 2 of the
User Guide--for the fifth time! After suffering a complete toss and redo
(including his lunch), TWMan meets with the dreaded Project Leader who
harbors secret desires to be <gasp> a writer. And now, we rejoin him (bet
you didn't know he was coming apart) in progress...

The P.L. says the team is committing to a Oct 1 beta release, only a two
week slippage after losing six or more man months of development. This
pariah of a chapter, Chapter 2, started on December 1 and I handed him
revision five on March 1. This project is a large Oracle database. I had
been documenting it around the screens, discussing how to use the main
functions and then any sub-functions or pass-thrus to other functions. the
way the P.L. has designed the system, when a user looks at person
demographics, s/he sees a hitlist (that's "hit list" for us regular folk) at
the top of the screen which has the names and any important information.
Below the hitlist are fields with more detail (updating as the user clicks
on individual rows of the hitlist). If desired, the user can display even
more detail by clicking on a button along the bottom of the screen and the
system pops up a non-modal sub-window. And here's the point. There are ten
buttons along the bottom of the screen, five of them display non-modal
sub-windows. The others are other functions and the usual Close and Main
buttons.

I documented the screen from the top down, left to right, so the non-modals
appeared in the doc after other function and before the Close and Main
buttons. There was nothing to differentiate any of the buttons from each
other, except their labels. So the P.L and I argued (he says we had a
quarrel). In the end, the buttons which called the non-modals became a
different color and the doc changed. A compromise solution. So, here's where
the writer became a designer (and got the ultimate thrill of moving text
around the chapter and writing new stuff to as explanatory text--button
color, etc).

Now, there's no SMR or Change Order, just an e-mail saying this change
affects only those screens where the developers can easily make the change.
So the final release will incorporate some screens where the non-modal
buttons are a different color and others where it stays the same. is there
no justice? Is this a job for conditional text? How do I do this; or do I
wait just before release and then write like hell, incorporating the changes
at the last minute?

This project makes me feel like the vaudeville act where the entertainer
spins more and more plates on top of slender rods. I keep spinnin' then
plates, trying not to drop anything, but feeling like I want to just stand
back and watch everything go critical....

Dennis Hays, The Burden Lake Group, Ltd.
Voice: 518/477-6388 Fax: 518/477-5006
E-Mail: dlhays -at- ix -dot- netcom -dot- com
"Write with fire; cut with ice."


Previous by Author: Opinions sought new pub/doc manage system
Next by Author: Re: Trends for Technical Communicators? -Reply
Previous by Thread: SGML Conference - Ottawa, Canada
Next by Thread: Adobe Acrobat


What this post helpful? Share it with friends and colleagues:


Sponsored Ads