Re: Single Sourcing and Thinking Bigger

[Graham Tillotson <Graham -at- MEGSINET -dot- NET>]

Recently, after two years with my nose in databases, I returned to
online help development and tackled the problem of "single sourcing,"
but in my database-oriented mind this concept is much bigger than
just the print v. online quandary.

On my current project I am using RoboHELP 7.0 to develop three
distinct deliverables--a context-sensitive help file, an online
tutorial, and a printed training manual. In MacGuyver style, I
am using Access on the back end to store user procedures and
glossary terms. This information is inserted into my Word files
via the {DATABASE} field, and I reformat the field content with
macros.

I consider this to be "single sourcing" primarily because of the
database, not the help files or the printed output. I see bigger
benefits with the database than with the Winhelp files, such as
integration with client databases, web publishing, concurrent
multi-user access, replication, etc. I consider the help files to
be extensions of my core database content.

Not surprisingly, I am a total convert to XML and am reading all
I can on the subject, because I'm convinced it is the future of
documentation. The challenge I see with single sourcing as we move
forward is one of information modeling--to work with XML (just as
with databases), you have to be able to separate content and
formatting. For many people, myself included, this is a very
difficult concept to grasp and an even more difficult skill to
develop. I don't think we can begin to talk about single sourcing
in its pure form until we treat all of our information (text,
graphics, audio, what have you) like database data and store
content/data in a platform-independent source completely apart
from formatting.

Any thoughts on this premise?

Graham Tillotson
Senior Consultant, Whittman-Hart
Chicago, IL

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