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: Baiting for the single source rant From:"Brierley, Sean" <Sean -at- Quodata -dot- Com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 6 Sep 2001 13:38:18 -0400
Andrew's points are understandable. As is Bill's tenacity. Here's my scoop:
As many have pointed out, single-sourcing can be poorly done. Writers can
take a document that was designed for print-only and re-purpose it into
online help with no effort. At best, these are examples of bad
single-sourcing. I recommend we do not judge single sourcing based on bad
examples.
For example, somebody can write really bad online help that is its own
project and not single-sourced. Should we use that bad online help as an
example of why creating separate online help projects is a bad idea?
Along those lines, somebody can write a really pathetic print-only document
that is not single-sourced. Should that bad print-only document be used as
an example of printed documentation projects everywhere?
Single-sourcing is its own project style with a plan and flow that is
necessarily different than online-help-only projects and print-only
projects. That is, would you write an online-help-only project using a
workflow designed for print-only deliverables? Of course not. So, why assume
single-source projects rely on online-help-only or print-only workflows,
they do not.
I would agree with Andrew's thought that single-sourcing workflows require
forethought and planning. And, while I recommend you put similar efforts
into online-help-only or print-only projects, it is a lot easier to start
pounding out text, monkey-like, for non-single-source efforts. If you get
paid by the word, for example, then single-sourcing does not pay.
I would also agree with many that single-sourcing workflow does not meet all
needs. Certainly, we do not expect print-only or online-help-only projects
to meet all needs, why do we expect single-sourcing to do so? There needs to
be a certain amount of content reuse for single-sourcing to work, there
needs to be stronger unity between writer, editor, and templates for
single-sourcing--though I recommend that, perhaps, for online-help-only and
print-only projects, you might want at least some small amount of conformity
to a standard style . . ..
One of the needs I think we forget about a lot is budgetary needs. That is,
there are _always_ financial restrictions on documentation. You might have
10,000 writers to document one small Visual Basic application, but are you
using quill and ink to scribe on paper trimmed with gold leaf? So, even
companies with the staff, time, and budget to create separate online help
and printed doc sets have limitations. Single-sourcing is especially
valuable for meeting such needs by making more efficient the process of
creating multiple format and multiple content deliverables. Yes, there is
some investment up-front, but it pays off in spades over the long-run. Is
short-term, up-front, investment in planning a problem for your company? If
so, consider whether the up-front investment is being done by dunderheads or
consider the overall long-term stability of the company that employs you . .
. if you are an employee with a family and debt or obligations, you might
want to seek a company that makes financial and project plans for a future
more distant than tomorrow at noon . . ..
Finally, I strongly recommend y'all re-read Eric Rays thoughts on this
issue--except Bill who is obviously already there--rather than judging
single-sourcing in general by bad examples and practices.
A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
+++ Miramo -- Database/XML publishing automation. See us at +++
+++ Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion +++
+++ More info: http://www.axialinfo.comhttp://www.miramo.com +++
---
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.
