Re: Mapping, Single Sourcing, odd situation

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

Wow. Great thread.

>> By the way, the ability to leverage related sets of information in such a
>> manner is one of the strongest arguments for using a database approach to
>> Single Sourcing of certain kinds of documentation.

<much snipped>

In her previous post, Gwen included the text from someone disagreeing with
her about single sourcing. That person objected to single sourcing as just
an excuse to burden the user with identical wording, just in different
formats.

That is not, repeat not, Simply Written's approach to single source and the
Clustar method. Huh-uh. Clustar does, indeed, require some compromises. So
does every system. In Clustar's case, it requires the writer(s) to be
extremely conscious of structure and be consistent "tho the heavens fall".
But the system also permits us to reuse vast amounts of text and "data" in
different areas and formats. A Clustar training manual doesn't have the same
stuff as a Clustar software manual, even for the same product.

If people are thinking that single sourcing means to just type once and
translate to HTML, that's not our view. Rather, we view single source as
writing information in ways that are *designed from the start* as
multi-output, because they're separable. The pieces can be reused in
infinite combinations. And we stress tasks, not data like field definitions.

We here firmly believe that single source, while definitely a boon to the
client's budget, is also easier to read, simpler to navigate, and much more
effective, if only because it focuses the writer on what's important and
doesn't encourage fishing expeditions. "Narrative" manuals are fun and often
artsy, but they're also frustrating as all get out for users who need task
help.

Tim Altom
Simply Written, Inc.
Featuring FrameMaker and the Clustar Method(TM)
"Better communication is a service to mankind."
317.562.9298
http://www.simplywritten.com


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