Reasons to structure

[russ at weststreetconsulting.com]

If you work for a company that doesn't accept qualified recommendations for improvement from its staff, you should keep a resume up-to-date. No company can last too long if it doesn't embrace innovation from the lower levels.

I think the truth is, actually, that in the majority of cases, tech writers are not qualified to proselytize on structure, because they haven't really learned about it yet. Hence my original point, several postings ago. You have to understand it to present a convincing business case (show them the money, as it were).  In the past several years, I've had relatively little difficulty getting acceptance from management for new tools, methods, etc., because I understand the benefits and can clearly enumerate the reasons for doing it.

I would like all tech writers to be this way, because I don't want us to be second class in the arena of ideas. When it comes to tools and methods involved with our work, we should be the primary influence on what happens. The key is, though, we need to know what we are talking about first. So I say, get in there and learn. I don't believe for a second that there are only a select few of us that can understand simple tools like structured Frame. You just need to have the desire and understanding of how important it is. 

 -------- Original Message --------
Subject:  RE: Reasons to structure
From: "Randall C. Reed" <randall.reed at forceprotection.net>
Date: Thu, February 15, 2007 9:11 am
To: <russ at weststreetconsulting.com>,<framers at lists.frameusers.com>

Russ West says: "It is so important for any tech writer to learn about
structured content..."

The funny thing is, in the majority of cases, we are not in a position
to proselytize for or against structured documentation. That's usually
decided several pay grades higher by contract deliverable or other
edict. We rarely. If ever, get to choose or even recommend! But a TW who
wishes to remain employable should be able to respond to structured or
unstructured requirements by being able to work in both. The general
trend in technical publishing, I predict (duh!), will require more
automation, more reusability, more interchangeability of data, not less.
If I had to bet on a winner in that horse race, my money would be on
more structured documentation, not less, in our collective future.