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.
>* 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?
As granular as you want it to be. You figure out what you want to set up
based on your resources and needs.
>* Context: When you convey a piece of information, how do you know the
user's
> ntext *a priori*?
The same way as you do or do not do for multi-source documents.
> I know about SGML, but our implementation, VAX DOCUMENT, wasn't up to
the
> sk. 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.
Just because you took the wrong approach doesn't invalidate everybody
else's approach or other approaches. There are several approaches that
work, including XML but not only XML. Again, since you get to define the
granularity and plan your approach, these issues are up to you.
> 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.
Doing those things adds to your single-souring burden, yes, but they are
not impossible to manage. And, you can control, limit, or exclude such
things by planning your single-sourcing adventure carefully.
> So... How much overlap are we talking about here? How much overlap
have you
> achieved?
It depends. Some (Sarah O'Keefe) would say you need a minimum of 40%
content reuse to make single sourcing worthwhile. I'd say, you need to
evaluate your resources and needs.
If you are currently repurposing one kind of file to create another and,
in effect, using a high percentage of content (as one might do for a
help file created from a printed doc or printed doc from a help file),
then single-sourcing is going to work great. OTOH, perhaps you have lots
of uses for your content but little overlap from one doc to the next. If
you are storing the chunks of content in a database anyway, and even
though there might be little overlap from one doc to another, because
you are frequently reusing chunks of data the process of single sourcing
becomes worthwhile. Does that make sense?
I feel it important to point out that you can fail at single sourcing,
just as you can fail at traditional multi sourcing. Failure is not
inherent in single-sourcing workflows, just as it is not inherent in
multi-sourcing workflows. Single-sourcing workflows might need more
planning, structure, and discipline than your average multi-sourcing
project, so in planning, structure, and discipline are not things you
enjoy or do well, I can see how you'd be prone to fail at the
single-sourcing thing; I tend not to be good at things I dislike,
either.
In other words, I see you suggesting the failure of single sourcing
because: 1) You have failed to do it in the past. 2) Some Apple thing
that neither of us is very familiar with. 3) Your failure to plan decide
on the granularity of your approach. 4) Your failure to understand the
context in which your customer needs the information.
I don't know whether single sourcing is right for your workflow, but I
recommend that planning can overcome your shortcomings and the failures
you see are your own and are not inherent in a single-sourcing workflow.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
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.
---
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.
