Why WYSIWYG for XML???

[Geoff Hart <ghart -at- videotron -dot- ca>]

Bill Lawrence wondered: <<... many writers, when considering going to 
XML, are looking for WYSIWYG authoring tools.  In my experience, using 
WYSIWYG tools are a real barrier to getting writers into the mindset of 
semantic markup versus visual layout. In training writers to use XML or 
SGML systems, especially those that will be using single-source systems 
designed for multiple output media, the big problem I've encountered is 
in getting folks to mark up content for it's meaning and not worry 
about the format.>>

I can think of two good reasons to request WYSIWYG. First, XML serves 
as an abstraction of the content, and abstractions are difficult to 
visualize until you've had considerable practice doing so. Even then, 
complex structures are difficult to visualize--which is why most of us 
use desktop publishing software to produce layouts instead of 
hand-coding layout tags and hoping the output will look good: we simply 
can't visualize the layout without a WYSIWYG option. That leads to the 
second reason:

Presentation and content are _both_ important. Single-sourcing, when 
_implemented carelessly_, creates "robodesigns" with no human oversight 
into the final look and feel.* This is NOT inevitably a part of single 
sourcing (well-designed output templates produce fewer problems), but 
the single-sourcing paradigm facilitates this problem: it's easy to 
focus on the content to the exclusion of the layout. Switching to a 
"what it will look like" mode provides a reality check on the tagging 
so you can ensure that you're actually producing what you think you're 
producing.

*N.B.: For online content, where the nature of the display device is 
beyond the designer's control and where content may be generated "on 
the fly", well-designed templates let users adjust the content to the 
available screen real estate and customize the information that is 
displayed. For print, however, the output is (or can be) fixed, and 
that's where purely automated layout fails: it removes any human input 
into the final design. Automated layout tools simply don't reliably 
produce high-quality print designs.

<<I've even had writers insist that unless they can control and 
override style sheet formatting they can't do an adequate job of 
creating documentation.  Never mind that the some pieces of the single 
source docs might be used for online help, some for PDF, and some for 
internal knowledge bases.  They want to see what it will look like on 
paper as they are writing.>>

I agree with them--in part. You must rigorously enforce your templates 
if you hope for single sourcing to work, but this doesn't mean you 
should permit barbarous designs to survive just because "that's the way 
the template is designed". Most of us have considerable knowledge of 
how to produce elegant and legible print designs, though not all of us 
succeed in using that training. But nobody has yet convinced me that we 
should abandon any say in the final layout.

The philosophy of "one size fits all" leads to Hart's corollary: "but 
it fits nobody well". That's an exaggeration, but the point remains 
valid: where we have design skill and time to use it, why shouldn't we? 
I'm not suggesting endless font fondling; I am suggesting that design 
requires human oversight.

Why not seek a compromise? Insist on adherence to the template during 
the content creation stages, but allow the use of WYSIWYG to help 
writers be confident that they're applying correct tagging: visual 
feedback and human review is more reassuring than tag validation, and 
often more accurate*. Last but not least, do a final pass 
("proofreading") to spot "layout" problems. No professional publisher 
eliminates the proofreading stage for print publishing. Why do we 
believe it could be eliminated for online publishing and single 
sourcing?

*My first experience with single sourcing: a GM car owner's manual in 
which several chunks of text had clearly been taken from the manual for 
an entirely different vehicle and were clearly irrelevant to my 
vehicle. This could have been avoided by human editing and 
proofreading. You _can_ provide this degree of oversight in single 
sourcing--if you remember to do so.

Any problems detected during proofreading would ideally be fixed by 
tweaking the template. I'd prefer to go beyond that and manually 
override the layout where necessary, as is routinely done in all 
desktop publishing operations, but recognize that this may not be 
possible in a true single-sourcing workflow.

<<I've also noticed that writers that fixate on WYSIWYG never really 
make the jump to semantic markup.>>

That's a more serious problem. Perhaps the compromise I've suggested 
would resolve it?

--Geoff Hart   ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)


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

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