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: Framemaker as authoring tool (postscript) From:Dan Brinegar <vr2link -at- VR2LINK -dot- COM> Date:Fri, 29 Jan 1999 02:09:05 -0700
It is often neither the forest nor the trees one should seek, Grasshopper,
but the tiger lurking in the shadows. Those yelling to you about the tiger
in a language you do not speak may just as well save their breaths.
On Thu, 28 Jan 1999 18:34:03, Tim Altom <taltom -at- SIMPLYWRITTEN -dot- COM> wrote:
[Re: Framemaker as authoring tool ... and structure done in advance before
any writing is done ]
"This may seem horribly restrictive"
For us Framers, I should point out, it's no-more restrictive than agreeing
to use the same language and alphabet: such structure makes things
workable.... once the busywork of defining structure is complete all ya
gotta do is write.
Sit a mainframe operator down in front of a Mac the first time, and he'll
absolutely freak...
Sit a Framer down in front of Word 97 the *first* time, and he'll be
paralyzed for minutes, hours or days trying to figure out where to start...
In Frame, the structure is (almost) everything...
If you've got 30 days to write a 300 page manual, and you've got either
less than 5 or more than 1000 pages of source material to sift thru, you
really don't have time to figure out your new employer's weird authoring
process if it's not at least reasonably similar to the weird processes
you've used in the past.
And then there's just plain text... and even that's getting a little funky
(anybody else get the boxes and "=" signs instead of punctuation in lots of
email recently ? 8-)
If you've got just 30 days to write a huge manual, better hope you're
devoting most of your time to playing with, breaking, and getting your head
around the PolyDentite Enmasticator system you're trying to document... and
not, as happened to me at least once, spending three weeks trying to
understand your tools before tackling the source docs and interrogating
engineers... sure we can always learn other tools, but do we have the time?
(he said, sputtering to a stop.... with many things left unsaid... and the
usual free-form punctuation he uses in informal chattering)...
No competing tools or documentation paradigms were harmed in the creation
of this message.
Sometimes, that which sounds like a dreadfully pointless and boring three
day contract can not only buy food next week, but turn into a special treat
involving meeting every computer user at a movie studio, seeing all their
toys, and talking to them. And what you thought would be a boring pointless
job punches your ticket to a nice secure contract... and you can read
TECHWR-L again without worrying about the prospect of being forced to turn
out a 300 page manual in TigerSlides 2000... which is a GOOD THING.
The World is once-again spinning in greased grooves, even the pain was
worth it: Send the nearest Pointy-Haired Boss or Clueless Agency Muffin a
little love and understanding today; it will add up and pay off at some
point... maybe not right away, maybe not tomorrow, but soon and for the
rest of your life.
Be well, TECHWR-L'ers!
dan'l
>[....] we don't
>experiment with formats either. That's also set up-front. After the writers
>and production people and layout people have their input, the project is on
>rails. No messin' around. Our production people do not, willy-nilly and at
>whim, create new tags or otherwise change our template. Let that sort of
>thing happen and pretty soon you have a foggy mess of unknowns that will
>eventually consume you.
>
>This may seem horribly restrictive, but as one very wise man said "a river
>without banks is a puddle". Growing software without specifications is an
>exercise in ego and futility. Growing a big manual is similarly futile.
>We've never yet seen a case where a large manual was grown by accretion, and
>had the project come in on time and on budget. Not once.
-----------------------------------------------------------
Dan BRINEGAR, Info Developer/Research Droid
CCDB Vr2Link Performance S u p p o r t Svcs.
