Re: Framemaker as authoring tool (postscript)

[Tim Altom <taltom -at- SIMPLYWRITTEN -dot- COM>]

I really think this needs a follow-up, if only because it cuts to the very
heart of how many of us look at documentation.

>I wonder, by the way, how many people distinguish between authoring and
>other parts of the job, like formatting or document management.  The
>book-publishing industry does, since different people do different jobs:
>normally the author writes in Word and the typesetter imports it into
>Frame.  But it seems that among tech writers, this distinction is not often
>made as clearly.  The authoring part usually gets short shrift (except on
>this list, of course).

We make a strong distinction, too...our writers write. They don't fiddle,
try, experiment, move things around, make formatting decisions, and on and
on. They write. And when they write, they write to a strong and unforgiving
outline, often to our own Clustar Method. No artistry once the project
starts. All artistry is used up in the planning stages. After that, it's an
engineering project.
>I think of authoring as the part where you create or discover the content
>and try out different ways to express it.  In other words, cranking out
>text, shuffling it around and tweaking it, fiddling with the organization,
>and, to a lesser extent, experimenting with different formats.

Not us. Not ever. We don't "discover" content. One writer's work for us is
almost interchangeable with another's. We don't shuffle, tweak, or fiddle
with the organization. The organization is more than 90% set before we
commence typing. That's why we make money even on hard jobs. And 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. But we do it
routinely. Our writers are professionals; they know that their artistry
comes in cajoling SMEs, picking their way through interfaces, choosing
graphics well, and using judgment in the inevitable decisions of what to
include and what to leave out. But they are never given the right or the
responsibility of changing anything structurally during a project.

I know this isn't how many of us work, but that's how we do it. And that's
why Frame is our runaway favorite tool. It's not the tool enforcing the
practice, but the other way around.

Tim Altom
Adobe Certified Expert, Acrobat
Simply Written, Inc.
The FrameMaker support people
Ask about Clustar Method training and consulting
317.899.5882
http://www.simplywritten.com




That's very
>different than stuff like printing crop marks, very fine control of
>placement via measurements you can enter in master pages, etc.  Clearly no
>other tool is in Frame's league there, but that's got only a little to do
>with the authoring side of the job.
>
>--
>Ben Kovitz <apteryx -at- chisp -dot- net>
>Author,  _Practical Software Requirements: A Manual of Content & Style_
>http://www.amazon.com/exec/obidos/ASIN/1884777597
>http://www.manning.com/Kovitz
>
>
>From ??? -at- ??? Sun Jan 00 00:00:00 0000==
>
>


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=