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.
| The discussion is starting to sound like a marketing presentation 8^)
I guess you haven't been to a real marketing presentation recently. ;-)
| Previously, I'd asked how much "overlap" of information
| we're talking about between different delivery media; the
| current bid is 90%. Wow! Is that in bytes or in words? In
| my experience with printed/Windows Help delivery, it
| was probably under 1% of the bytes (because there were
| no graphics shared)
It's difficult to imagine what possible relevance byte overlap could
have to this discussion, or how it could inform decisions about how to
produce and deliver content. Is this a serious argument?
| and under 30% of the words (because
| the Help was almost entirely procedural,
| with no concepts or system responses documented online).
Well, it's certainly unusual for 70% of the words in a technical
document to be devoted to concepts and system responses. And the
omission of all graphics and response statements from online Help is
sort of a vintage 1997 approach. However, since we're talking about the
capabilities of single source systems and not about effective
information design, I'll ignore these points.
The examples you give -- needing to omit result statements and graphics
from online versions of a document -- can *as a matter of fact* be
solved trivially by any true single sourcing system. You apply tags like
SystemResponse and Graphic in your source documents, and when generating
the online output, these elements are automatically omitted.
If you're looking for an example to show why single sourcing cannot
work, you'll have to come up with something much more challenging than
| Also, in the spirit of regarding all problems as either
| insoluble or trivial, we're now assured that all problems
| are handled by a "system." I'm relieved
| to hear that! I thought these were real problems 8^)
| I guess before I sign the purchase order, I'd like to see some
| examples and sample code...
If you have a substantive rebuttal to make, I'm sure we'd all be
interested in hearing it. Simply disparaging the arguments of others
without offering substantive replies does not, it seems to me, advance
I agree with Sean that you have decided single sourcing cannot work
based on a 10-year-old experiment with VAX DOCUMENT (an experiment that
was never completed) and some assumptions about the single source
process that are simply not correct. (Oh yes, and something about Fat
Mac binaries which is all about compiling code and has no bearing
whatever on single sourcing information.)
Consulting & Training on FrameMaker & WebWorks Publisher
Consulting & Training on RoboHelp
WebWorks Publisher Certified
Member, JavaHelp 2.0 Expert Group
Moderator, HATT & wwp-users
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.