TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:RE: Of myth and reality From:SteveFJong -at- aol -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Sat, 20 Jul 2002 13:27:24 EDT
Sean, we seem to have different images of "single-sourcing," which allows you
to argue in consecutive paragraphs of your reply that (a) a "single-source"
document that contains separate blocks of text for printing and online
display isn't single-sourced, (b) unless you want it to be:
(a) >> I never made a claim that that was single sourcing.
>> Why do you say that I did? Why did you even bring that up?
(b) >> Why must single-sourced documents all have the same content and/or
>> all have the same graphics and/or all have the same layout and/or
>> all have the same fonts and/or all have the same use of color, etc.?
I believe you're saying that if I write the same thing differently in two
blocks, I'm not single-sourcing, but if you write two different things, you
are. Hmm ...
The Macintosh "fat binary" analogy is quite apt, I think. The "fat binary"
contained separate code for the 68K chip instruction set and the PPC
instruction set, though the application could share resources (graphics, sou
nd, data, etc.). It was a single application from the user's perspective,
though it was bigger, always contained dead code, and wasn't guaranteed to
work the same on both platforms because the code was maintained separately.
Despite Apple's assurances it was very easy to implement, I gather it was a
pain in the neck, and it's not missed. To me, that's not single-sourcing,
that's creative packaging.
A more direct historical precedent might be the S.S. Digital's attempt to
create a reusable database of information modules, which foundered on the
rocks of granularity and context:
* Granularity: How small must a module be? A map? A topic? A procedure? A
paragraph? An illustration? A sentence? Unfortunately, yes... at which point
the working writers' eyes glazed over, and who could blame them?
* Context: When you convey a piece of information, how do you know the user's
context *a priori*? If you're talking about database backup, are you dealing
with an experienced administrator (for whom it might be sufficient to write:
"Use the dBackup command; ensure that you have 150% of the database size free
on the backup media"), a beginner (for whom you would have to write in
considerably more detail), or a student (for whom you would have to create
and step through an example)? No matter how much we were told we didn't have
to write differently for different contexts, we found that we did.
I know about SGML, but our implementation, VAX DOCUMENT, wasn't up to the
task. Ten years later, XML has emerged as a practical means of reconsidering
the problem (<yadda></yadda>), but few writing organizations are large enough
to make it a cost-effective approach. And even at that, I expect the problems
of granularity and context remain.
I think it would help to have a single definition of "single-sourcing" that
includes the concept of create-once, use-everywhere. If you have to write a
block of text twice or more, or modify a graphic twice or more, for different
presentations, then you're short of the goal. I don't demand 100% confo
rmance; I'm realistic about the expectations of our audiences and the
limitations of our tools. But clearly we want to get as close as practicable.
If we agree on that, then the question becomes one of overlap. If I have to
jump through hoops so that I can have one file, or set of files, that
contains printed and online (and Web and PDA or ...) information without
significant overlap, I'm going to ask what benefit this has for the user and
how much time and effort I'm saving as the creator/maintainer of the file(s).
So... How much overlap are we talking about here? How much overlap have you
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
Buy RoboHelp Deluxe starting at only $798: you'll get RoboDemo, the hot new
software demonstration tool that's taking the Help authoring world by storm,
together with RoboHelp Office. Learn more at http://www.ehelp.com/techwr-l
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.