Formatting Chaos - Pt2

[Dan Azlin <dazlin -at- SHORE -dot- NET>]

Thanks for everyone's input. Here's a collective response...

To Rebecca Phillips: The client is using FrameMaker on both PC and Unix
platforms. There is minimal understanding within this company of how to use
Frame, especially its more "advanced" features like templates,
autonumbering, cross-referencing, etc. A significant amount of my time in
the last few months has been spent in informal training of the other writers
and consolidating a standard template for my projects and anyone else's who
wants to use it (with my quiet encouragement). Unfortunately, this tech
writer want-to-be has a hate/hate relationship with Frame and every other
Page Layout or Word Processing package out there -- except for AmiPro (which
he's in love with). But, because this company has standardized on FrameMaker
or Word, he struggles loudly. (Unfortunately his whining paid off when his
manager let him get a PC several months ago to replace his X-terminal on the
unix network.)

BTW, the hostility was only from this "writer," not the company. Sadly, the
manage responsible for TechPubs is also responsible for Field Service. Guess
where the lion's share of his attention goes?

To Alisa Dean:  I doubt upper management understands the first thing about
technical documentation process; nor do they wish to. This company is in a
critical phase of its growth: outgrowing its management structure,
struggling with unhappy customers, and in a fog about the inherent dangers
of their long standing lazze faire corporate culture. Bigger problems (read
that: squeakier wheels) have their attention.

Yes. This guy is breaking every rule in the book regarding good
communication. You see, he's never read the book (though he is proud of his
grammarian reading list), and believes that he can write it himself.

I once did a set of manuals for a software company that wanted to mix and
match their manuals based on the mix of products ordered by each customer.
For their product line (software libraries) this made sense. Yet each manual
was a standalone document written in a consistant format. A centralized
TOC/index was not appropriate in this instance. But for this current
client's product line, the customer's expectation is that his $1M or so
investment warrants a set of dedicated product manuals.  In fact, in the
industrial arena where these kinds of products are used, down-time on a
machine cost thousands for every hour it is "off line." In that situation,
the interest is in quickly and efficiently fixing the problem, not in wading
through an encyclopedia of technical minutia in the hope that a solution
might fall out. I know this from first hand experience in my earlier
engineering life.

To this guy, he believes that his modularization is "intuitive" to the
reader and that the intuitive structure will lead him to find the
information that he seeks. But... when he find the information, he will have
to take the time to sit down and LEARN the underlying principals of the
technology to gleen the solution to his problem. { -at- insert dirty_word}

To Bill Sullivan: Yeah, he's going to crash and burn. I've tried to help
minimize the potential damage, but my offers have been mostly rejected. In a
meeting that we had late yesterday, the Tech Pubs/Field Service Manager and
I talked about several things. I have suggested to him on several past
occasions that this grand opus is poorly conceived and too extreme in
ignoring the conventions of good technical communication/documentation. Now,
I suspect that the situation is nearing critical mass with this mandate to
distribute review copies on Monday to a select list of reviewers (myself
included). I have suggested that this should be looked upon not as a simple
review, but also as a usability evaluation. He agreed.

Is he on to something? Well, in all honesty, there are enough good ideas
sprinkled through this mess that something good may come out of it.
Consolidating source material (parts of which are duplicated in several
documents) in a central library of documents with limited internal scope,
and serving as component parts of a larger product specific document makes a
lot of sense.  But the idea of a single massive tome of encyclopedic scope
and a fundamental dependance on the reader as eternal student, prodded by a
vague document organization lacking a recognizable navigational structure,
is something from a bad LSD trip.  My best opinion is that this individual
simply doesn't understand how to craft a document for a specific purpose
other than his own.

re Politics:  There be dragons lurking in these fields.  As a consultant I
have to tread lightly. I cannot come out and say that this guy is wacko
(though a psychologist friend of mine has ventured the third handed opinion
that the guy may be obsessive-compulsive). Nor can I tell senior management
what numbskulls they are. What I can do is talk about ideas that they find
exciting (ISO 9000, Electronic Publishing, Web Pages, Project Management,
Documentation Process Control...). Yeah, I slip in little lessons about
business and life and documentation standards. Baby steps.

Unless I am given some kind of mandate, there is little else I can do other
than be ready to step in and pick up the pieces when the storm blows over.

To Wayne Douglas: Blake = 1, Peasants = 0.
And the idiots name is.........  No, let's let him remain nameless to
protect the guilty.

Thanks again to all for the words of support.
Dan Azlin ** WORD ENGINEERS, Technical Writing & Publishing **
dazlin -at- shore -dot- net                              7 Myrtle Street
ph/fax 508-921-8908                          Beverly, MA 01915-3315

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html