Re: Single Sourcing, response

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

And Christine said...


>Okay,
>
>I hear you all saying that you really can't single source -- that web-based
doc is
>inherently different in structure and complexity that print.  So, of
course, there
>is no technological solution -- no matter how hard I look, I won't find
some
>combination of Frame/webimport-export software that will allow me to create
both
>HTML and PDF versions of my doc.  Well, if that is true, then aren't we
saying we
>will forever be saddled with an almost impossible maintenance problem?

Yes, practically speaking that's what I and others are saying, but again if
all you want is text over here.....now text over here, then single source is
a matter of pressing a button and filtering data. You can convert anything
to HTML with a filter. But it's not necessarily good stuff. A sausage
grinder converts things, but it doesn't pick out the bad parts. The
maintenance problem comes out of a desire to do both at least passably well.
And therein is the rub.

This is partly why we use Frame, with its conditional text feature. We can
show or hide any combination of dozens of different permutations of a
document, all at a mouse click. But this takes, requires and makes
indispensable *planning and discipline*. You won't get good results without
them. The tools will parse and filter garbage as readily as gold.

Let me reiterate Simply Written's position: First in any single source
project is planning the document specifically for single source. "War and
Peace" won't do well as a single source. And planning begins with analysis
of both users and tasks. Notice there's no mention of tools here. That comes
a lot later.

This, of course, may mean a total overhaul of how documents are being done
now. That's sad, but inevitable I think. Before business cards can be
rendered to a database, they must be scanned or typed into a specific DB
format. It's the same with anything that must cross conceptual boundaries.
Playscripts and poetry are meant to be spoken, so they don't always read
well on the page. Documents that are intended from the start for hypertext
and print *must* be designed for that purpose, regardless of how they're
currently structured. Structure is the key. That's what the Clustar Method
is all about: analysis and structure. We use Frame as an enabler, but it's
not required.

Sure, hypertext and print are quite different, but with the proper
structural design they can both be adequately served. Neither will be
maximally served, of course, but if you've got the money and time and staff
to do both extremely well, then be thankful and let single source go. But
for the thousands of us squeezed in the middle, methods like Clustar can
make all the difference. It has for Simply Written, I can tell you.

Tim Altom
Adobe Certified Expert, Acrobat
Simply Written, Inc.
The FrameMaker support people
We train and consult on the Clustar Method
for single source documentation
317.562-9298
http://www.simplywritten.com

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