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, you answer to my granularity question was "as
::: granular as you want it
::: to be," which is, I think, imprecise; you probably mean "as
::: granular as you
::: need it to be."
Have we reverted back to social grooming? How many nits are we going to
::: My concern, based on watching working writers confront
::: this issue, is that their answer is, "I don't want to be
::: that granular." As
::: the effort to maintain a single source rises, compliance
I think you're hitting a management issue there. First, you NEVER
introduce a new workflow without first getting feedback from the team
and then getting approval of the proposal and buy-in for the workflow.
THEN, if you hit this issue, well, if they agreed, they suck it up. I
hate to say it, but it's love it or leave it. They bought into it, they
suck it up. If it was forced on them, well, then shame on the
ringleader. May he/she be burned alive at the next team luncheon. ;) If
you CAN'T get buy in from your writers to get that granular, guess what?
YOU DON'T IMPLEMENT THE WORKFLOW! (Or you get writers who will buy into
it... The market's right for it, I'm sorry to say. Oh, and before anyone
starts with the "how dare you" replies, I know what it's like to be
unemployed. I was laid off three times in the past 2 years, and I just
went back to work full time this morning after being laid off in April.)
The point is to do your homework, analyze your needs, and act
accordingly. Hey, just like good ol' tech writing, huh? Different
mechanics, same practice.
::: As for context, you're on the dock yourself. Multi-source
::: documents solve the
::: context problem by having, well, multiple sources.
::: Single-source documents
::: need another solution--writing two different text blocks
::: doesn't count. (If
::: you can thread together pedagogical material, procedure,
::: and reference
::: material into a single block, you're a better writer than I am 8^)
You're assuming 100% (or similar) reuse. With anything, it depends on
the content, audience, and deliverables.
::: As for VAX DOCUMENT, I can assume no credit or blame. I'm
::: not talking about
::: my personal attempt to single-source; I'm talking about the entire
::: corporation's multiyear effort to find economies between
::: technical writers
::: and instructional designers. While the corporate group was
::: using DOCUMENT, we
::: were off by ourselves, using Interleaf and watching the
::: flames shoot up. (I
::: think they're still wetting down the ashes 8^( It wasn't
::: the wrong approach,
::: it was the wrong implementation. For instance, tag
::: definition was restricted
::: to corporate template designers--you can see how that would
::: put a crimp in
::: our style. (I'll value your new approaches if you'll value
::: my experience 8^)
I can appreciate your experience. Have you learned from it? I can
appreciate your skeptical approach, but at some point you have to stop
looking at the high level details and get down into the nuts and bolts,
note where the failures were, and plan to address those failures moving
::: I see you quoted a figure of 40% content reuse as the point where
::: single-sourcing becomes cost-effective. I can live with
::: that, but doesn't it
::: matter how much content there is in total? Trying to
::: single-source at a small
::: company with one product would hardly be the Platonic
::: ideal, but the bigger
::: the library, the more worthwhile sharing or single-sourcing becomes.
Right. Which is why anyone looking into single-sourcing should compute
their projected ROI before going into it (just as with any business
decision or project planning effort).
::: It's true I have been referring to a print/WinHelp project.
::: I'd be interested
::: to read your views on how changing the display engine
::: changes the audience's
::: information needs...
The display engine is irrelevant. It's how the audience will use the
information that counts.
::: Assuming you are at peace with granularity and context
::: issues, I can see how
::: XML (at least--you're not committing to a specific
::: solution) could be made to
::: work. It would be interesting to see a small sample.
How about a big sample? Might not be ideally what you're looking for,
but check out most online newspapers.
B I L L S W A L L O W
Information Design & Development Professional
tel/fax: 518.371.1867 wswallow -at- nycap -dot- rr -dot- com
List Owner: HATT, WWP-Users, InFrame
WebWorks Wizard Editor of InFrame Magazine
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.