Single Sores

[Andrew Plato <intrepid_es -at- yahoo -dot- com>]

Lots of good discussion about this topic. I'll respond to Bill and other
comments with something I said a long time ago on this topic.

Any SS endevour must begin with the team asking itself the following
questions:

1. Do we have a lot of time (months perhaps) to design, test, and enhance
a complex SS system? 

2. Is the content of the documents: 

   a. Stable, that is not prone to wild changes in tone, direction, or
basic content?
   b. Lend itself to a high degree of organization?
   c. Straightforward, that is not requiring extensive audience education?

   d. Well understood, at a technical level, by all writers involved?

3. Are we willing to scrap the system at a moment's notice to fulfill a
deliverable?

4. Can it produce a tangible benefit down the road that will save money
and time without negatively affecting the quality of the material?

5. Are we able to adequately generate documentation using "traditional
methods?"

6. Do we have buy-in from all related parties, including engineering and
management folks?

7. Can the team professionally select designs and templates without
in-fighting? 

If a group can answer yes to all these question, then you're probably
ready for SS. If you cannot, you have more work to do. 

I would estimate that 1 in 10 perhaps 1 in 20 organizations could answer
all these questions yes. I would also estimate that most of these
organizations would be dealing with the maintenance and management of
large doc sets, regarding relatively straightforward technologies that are
not prone to massive changes in design and concept. 

One of my problems with SS is the distillation of information. It has a
tendency to reduce the overall conceptual cohesion of a document. SS docs
often read in a herky-jerky manner because the chunks of information were
written by different authors, at different times, with different levels of
skill with the content. You also see a lot of material that was obviously
written by an engineer and lightly wordsmithed by the writer. 

The best SS system would evolve naturally from an existing set of docs
where writers, intimately familiar with the content, slowly manouever it
into processes that allow them to more rapidly reuse the material they've
written. But those writers are always prepared to scrap their entire
system to generate new content when it become necessary. I've gently
nudged projects this direction with great success. We don't SS the entire
doc set on day one, we slowly nudge bits and pieces that lend themselves
to a high degree of organization and reusability. We've don't this using
*gasp* Microsoft Word and Access databases. 

However, if you listen to the STC conference rhetoric, its always "SET UP
A SINGLE SOURCING IMMEDIATELY!" This is yet another area where STC is off
the map in La La Land. Preaching solutions to writers (or at least giving
them a forum to do so) without really assessing the message. 

> Can you give me/us an idea of what tools you speak of and what this
> "nonsense work" is that you speak of? It's hard to objectively weigh
> such a vague comment.

I've looked into numerous tools used for SS. Many are crude. Plain and
simple, they have terrible interfaces, esoteric commands, and bizarro
usage. The nonsense work is the extensive design and customization
necessary to get these tools to a point of usefulness.

That isn't to say these tools aren't useful, it just that there is a lot
of upfront overhead to get them there. 

> First, let's not talk single-sourcing
> and
> Information Mapping(tm) in the same context, as they are not the same
> thing.

I lump them together because they are both heavily hyped things. Both fall
into the same category for me: things that writers use to avoid doing
their real job. 

(I am waiting for that item on the $64,000 pyramid. Can't you see it,
Jamie Farr is sitting in front of me saying "Information Mapping, Single
Sourcing, Fonts, Templates, STC Conferences."  And I yell "Things
technical writers use to avoid their real jobs!"  Ding, ding, ding, Dick
Clark comes and shakes my hand.) 

The problem is that people who have had successful SS experiences assume
that their experience is universally applicable. "If it worked here, it
will work everywhere."  Most organizations are not ready, nor will they
probably ever be ready for SS. 

I understand this thinking, but its logically flawed. Its natural to
assume that what you know and is comfortable is always correct and proper.
This problem is endemic to any industry where there is a high degree of
personal input into the outcome. 

The bottom line - you want to SS: 

1. Get to know the content first.
2. Write the docs, the "hard way."
3. Publish them and make readers happy.
4. Then nudge your processes into more organized system. 

There you go.

Andrew Plato 





__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

A landmark hotel, one of America's most beautiful cities, and 
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe.  http://ieeepcs.org/2001/

  +++  Miramo -- Database/XML publishing automation.  See us at  +++
  +++  Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion  +++
  +++ More info: http://www.axialinfo.com  http://www.miramo.com +++

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.