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.
Bill Lawrence wrote:
>
> 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.
Yes, still following, Scratching my head a little, but still following. Let
me give this one more try:
The issue of WYSIWYG vs. markup (howsoever you design it and edit it) is
entirely beside the point. Think of it this way. WYSIWYG is slightly
misnamed. It should be WYSIWCS: What You See Is What the Customer Sees. It
means that you are directly handcrafting the final presentation of the
document. That means that, apart from physical production, you have a one
step process. Everything from composition, to organization, to formatting is
done in one step by one person. Taht is precisely what desktop publishing
promised. This one-step process has several advantages and several
disadvantages. In some situations, the disadvantages outweigh the
advantages. In these cases, you need to switch to a modular process
consisting of several discrete steps.
In such a process, only the last step produces what the customer sees. Each
of the other steps needs to produce what the next step needs as input. What
each step needs is the data to be processed and the metadata that identifies
the parts of that data so that they can be processed correctly. XML is an
excellent format for capturing this data and transporting it between stages.
The best interface for authoring in such a process is the one that makes it
easiest for the author to produce the data and metadata required by the next
stage in the process. That usually does not mean working in the literal
input format of the next process, but working in a lucid environment that
makes it easiest for the author to supply the information required. Part of
what makes many markup solutions difficult to use is the failure to supply
this lucid authoring interface. The solution, however, is not to switch to a
WYSIWCS environment, because such an environment will not capture the
information needed by the next step in the modular process.
So here's what you have to do. First, decide if you want a monolithic
content development process or a modular one. Once that decision is made,
choose the most lucid authoring environment for the process you have chosen.
For a monolithic process, the choice will usually be WYSIWCS. For a modular
process it will certainly not be WYSIWCS. It might be raw lucid markup, or
lucid markup in a structured editor, or a lucid forms based environment. It
depends on both the nature of the process and the nature of the content.
There is no single right answer (and anyone who suggests that there is is
making an unjustified extrapolation from individual experience).
The issue is monolithic process vs. modular process. My position on this
issue is that, for the vast majority of technical communication development,
a modular process is more efficient and creates higher quality. Thus I frown
on WYSIWCS tools because I see that they tie people to inefficient
processes.
When people say that they want to move to XML but keep WYSIWCS tools I
conclude either that they want to continue to use a monolithic process, in
which case XML will do them no good, or they want a modular process but
don't know how to create a lucid authoring interface and are falling back on
a familiar, but in this case inappropriate, process.
BTW, many content management solutions implement a modular process by
starting with a content reclamation step that takes the output of a
monolithic process and add the information needed to make it work as the
input to their modular process. They do this because they have no control
over the source of the content or the authoring process that creates it.
There should be no reason for technical communication to adopt this costly
and error-prone approach.
---
Mark Baker
Analecta Communications
www.analecta.com
+1 613 614 5881
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.
