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.
>
> Ok, let me start with a controversial rhetorical question. Are we now
> saying that technical writers should be tools weenies over and above
> subject-matter experts
I guess I would argue that as a writer you should write, unless you've
been specifically hired to do more than that.
> The goal is specifically *not* "single-sourcing" to Print, Help, HTML,
> Cell Phones, and Play Stations. OTOH, when a bill goes from one
> congressional body to another, then the look must change to match the
> given "house".
You've just provided a perfect example of why you should separate form
from content.
> These folks who draft these things are *busy* people. It's amazing
(and
> an honor) that they take enough interest in the tools to provide test
> cases, try out beta versions, help specify the requirements, etc.
> Clearly, they're motivated. But they're not motivated to learn how to
> edit this stuff in angle-brackets. In fact, anything that falls too
> short of WYSIWYG is simply not acceptable. They use *visual* cues to
> maintain their notions of hierarchy, emphasis, and other things of
> import - things that are transmitted via formatting.
You've limited your view of the editing environment to either angle
brackets or WYSIWYG. It seems to me that you and those busy folks would
be far better served by designing a guided authoring environment of some
sort, likely forms based. I believe Mark Baker (if he's still following
this thread) could probably elaborate on that. Also, nothing says that
you can't provide visual cues via a stylesheet. Equally, nothing says
that those visual cues must accurately reflect the output for one house
or the other. They are, after all, really only visual cues.
> LESSONS LEARNED:
> 1) Not all writing projects are based on manuals that are
> "multi-purposed" to print, HTML, and Help.
True. My point was particular to XML and technical documentation.
> 2) There is a vast universe of writing that is grounded in tradition
> (we've had laws for some time now), and requires subject-matter
> expertise to a degree that makes learning angle-brackets not an
> annyoance, but a real impediment.
You could make that argument about learning anything beyond the
subject-matter necessary. However, I wasn't implying that non-WYSIWYG
tools be applied there. I did mention that for marketing communications
I use Quark Express and I very much depend on its WYSIWYG output for
that sort of thing.
> And this is not a lesson learned here, but an observation. There's
> nothing to say that you must use WYSIWYG when creating XML. The
> question should really be, why don't I get to control the presentation
> of the information as I'm authoring it, so I can see it in the form
most
> useful to me?
If the output is one medium, there's no harm in it EXCEPT that you have
yet to separate form from content. For something as simple as a bill,
I'm sure that's fine. It's equally fine if you're doing a one-shot
piece, such as a flyer or an ad. But what if the semantics really
matter throughout? What if you're documenting an API, where every
function, method, class, variable, you-name-it must be marked
appropriately so that one can, from the single source, build
quick-reference cards, context sensitive help, and reference guides? I
would argue that your objections are probably valid given what you're
creating. However, the bulk of us on this list are creating technical
documents, and they are quite different.
Frankly, I don't care if the great masses of writers embrace XML or not,
nor am I suggesting that WYSIWYG tools aren't useful for many writing
tasks. I do care that people doing technical writing begin to think
beyond the mere appearance of the documents they create and concentrate
on the content and the semantics.
SEE THE ALL NEW ROBOHELP X5 IN ACTION: RoboHelp X5 is a giant leap forward
in Help authoring technology, featuring Word 2003 support, Content
Management, Multi-Author support, PDF and XML support and much more! http://www.macromedia.com/go/techwrldemo
>From a single set of Word documents, create online Help and printed
documentation with ComponentOne Doc-To-Help 7 Professional, a new yearly
subscription service offering free updates and upgrades, support, and more. http://www.doctohelp.com
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -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.
