RE: Why WYSIWYG for XML???

[Chris Despopoulos <cud -at- telecable -dot- es>]

STOP ME BEFORE I TYPE AGAIN!

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?  Have I not seen some switching of sides here 
(much as I saw staunch conservatives argue that pornography isn't a bad 
thing in the Clarence Thomas hearings)?

Let me use a real-world example.  I have had the pleasureof working on a 
project to bring structure and semantical markup to the process of 
drafting laws for a world-famous gvmt.  A few things of note:

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".  Ok, so that's single-sourcing, but only the look is to 
change, so one could *ostensibly* accomplish that with templates alone. 

The final output for a given house must look a certain way, and requires 
gvmt fiat (read tax-funded committees) to change the "look and feel". 

The processing advantages that come with markup are worth the cost.  
What bills does the current bill cite?  What bills cite the current 
bill?  What amendments are accepted, rejected, in-process, and where are 
they in process?  Who sponsired the bill, and for this phase of debate 
is that important?  I'm sure you can see the possibilities are rich.

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.

LESSONS LEARNED:
1)  Not all writing projects are based on manuals that are 
"multi-purposed" to print, HTML, and Help. 

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.  

3)  In this particular case, bringing the legion of "writers" up to 
speed on XML would amount to socializing the support of XML.  These 
people are paid by the tax payer.  In their wisdom (whatever you judge 
that to be) they determined that the cost of implementing a WYSIWYG 
interface to the semantic markup was far and away less than the cost of 
hammering their co-workers into an XML world-view.  (And I'd be willing 
to bet that the Americans most stridently arguing against WYSIWYG are 
among those who most stridently argue in favor of free markets and 
against socializing technology.)

4)  If XML is to be widely accepted, it must be presentable to a wide 
range of users.

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?  Nothing stops a FrameMaker user from tweaking his 
template/EDD so he sees his units in chunks of whatever size and 
format.  If you want Courrier for all your elements, you can have it.  
If you want a separate page for every <para>, you can have it.  
Actually, people do this all the time.  And they also do it with DTDs - 
why use the same DTD for editing small chunks vs compiling the final book?

I understand that the WYSIWYG requirement imposes a cost in both money 
and time to market for XML tools.  But it just may be worth it.  It just 
may be a requirement before the vast majority of people who product the 
world's written knowledge will ever put their knowledge into the more 
processor-friendly form known as XML.



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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