Re: Of myth and reality
::: So I concede Jan is right, for the most part 8^) But my point about ::: single-sourcing is reinforced. Write-once, compile-many is ::: single-sourcing, ::: and we both agree on that. However, if you write a block of ::: text that can be ::: printed as is, but is only good for the most part online, ::: and has slight ::: differences in a different target medium, the value of ::: maintaining a single source is diminished.
Which is where a tagged structure with conditional elements comes in
handy. You can, for example, author the paragraph with both online and
print elements in use, and then select one element type or the other
when you need to publish.
I would argue that while you _can_, you really don't want to. And you especially don't want to set up such a protocol for other (lesser, newer) writers to follow.
The downside of such an approach is that in the middle of considering who your audience is composed of, what it is you want to tell the reader, how best to phrase that, what the company style guide says about the subject, and the relationship between this paragraph and the thoughts that precede and follow, you don't want to stop to consider all of that stuff in two contexts. That's just too many balls to keep in the air at one time, and productivity--not to mention mental health--has to suffer.
Conditional elements have their uses (instructor notes, for example, or platform issues). Primarily I see conditional elements as being dependent on the audience, not the medium. If I am writing for the benefit of a system administrator, it doesn't matter to me whether that system administrator is reading print or online text. It does matter that I may need to expose certain details to the administrator that I'll hide for the user.
So in some sense using conditional elements is a form of single-sourcing (one source, multiple audiences).
However, I think of single-sourcing more in terms of one text, multiple media. And for this purpose, asking the author to handle the variants while writing seems inefficient. It makes much more sense to build the intelligence into the authoring _system_ rather than the authoring _person_.
Here's a typical example. I want to incorporate a figure to help me explain a concept. I need a TIFF or an EPS for print, and I need a JPEG or a PNG for online. In fact, I need a high-res version for people on a fast connection and a low-res version for people on dial-up. As the author, I should need only to say what figure I want. I should not have to identify three files and tag them. The system should be able to figure out the rest.
Similarly, I should be able to incorporate all sorts of typographic niceties (em dashes, curly quotes, piece fraction, equations, exotic tables) in the source, and the system should be able to degrade that source gracefully for everything from Web pages to plain text email.
Or I should be able to select XML tags to identify items and prices in a table and later decide whether to pull the wholesale or retail prices or to leave them out altogether.
My two cents.
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.
- RE: Of myth and reality, David Knopf
RE: Re(2): Of myth and reality: From: Bill Swallow
Visit TechWhirl's Other Sites