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.
> Sean Brierly's passionate defense of single-sourcing was itself based
on an assumption that
> I think is questionable.
As stated, my problem with the article is that is uses, as its premise,
the debunking of single sourcing. Instead of writing about how to
differentiate between printed documentation and online help, regardless
of how you get there, the article requires you to buy the fact that
single-sourcing doesn't work as a focal point for creating online help.
I submit that an article that only discussed how to differentiate
between printed documentation and online help could have been applied to
_both_ single sourcing and traditional methods of documentation.
I don't find that debunking single sourcing was necessary to set up a
discussion on the differences between online help and printed
documentation, do you?
> When the Apple Macintosh supported two CPU chip architectures, the
older 68000 and the newer G3,
> applications were often created in "fat" versions that would run on
either by dint of containing code for
> both. A "fat" application was a single file, but to implement a change
that would appear on both platforms, > the developer had to make the
change twice, in two different places and two different ways.
> Would you call that single sourcing? I wouldn't, and I don't think
Apple ever
> pretended that it was. Similarly, a "single-source" document that
contains
> separate text blocks for printing and online display isn't singular,
either.
Huh? I never made a claim that that was single sourcing. Why do you say
that I did? Why did you even bring that up?
> Clearly, the situation Lisa Wright <liwright -at- earthlink -dot- net> describes
is an
> uncomfortable one. If you're writing the same block of text twice, you
have a
> problem. But if nothing else, the graphical demands (or at least
styles) of
> printed and online documentation seem irreconcilable: you can't have
too many
> graphics in a document, and you pretty much can't have graphics online
(or so
> you all say 8^) The printed version is apparently the "fat" one!
Huh? 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.? If I
want my single-sourced online help _not_ to have graphics and my
single-sourced printed document _to_ have graphics then, guess what? The
online help does not have graphics and the printed doc does.
> In my last group, we talked about (but didn't implement) converting
I have to ask, what group was that?
> FrameMaker files into online help by grabbing blocks marked with
specific
> tags; for example, everything formatted with "Headline," "Summary,"
and
Yadda yadda. Are you reversing yourself and now supporting Sean
Brierley?
> Can you have a "single-source" document where the print and online
versions
> are proper subsets with significant overlap?
How can you question my discussion if you don't know?
Here's the deal:
1) If you can do it with traditional stand-alone online help, you can do
it with single sourcing.
2) If you can do it with traditional stand-alone printed documentation,
you can do it with single sourcing.
3) Just as traditional stand-alone documents fail, fail to meet their
audience's needs, fail to be accurate, and fail in their formatting,
etc., so too can single sourcing fail, for many of the same reasons.
4)Just as traditional stand-alone documents succeed, so too can single
sourcing succeed, for many of the same reasons.
5) Single sourcing is not always appropriate. But, when it is, it saves
you time, money, staff, and resources over traditional multi-sourcing
and helps you improve the quality of your documentation. And,
formatting, look, feel, and pop-ups are not sacrificed.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
