Why WYSIWYG for XML???

Subject: Why WYSIWYG for XML???
From: Geoff Hart <ghart -at- videotron -dot- ca>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 18 May 2004 11:56:57 -0400

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

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.

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.

Why WYSIWYG for XML???: From: Bill Lawrence

Previous by Author: Convert table-intensive word doc to .pdf?
Next by Author: Chicken or the egg?
Previous by Thread: Re: Why WYSIWYG for XML???
Next by Thread: RE: Why WYSIWYG for XML???

What this post helpful? Share it with friends and colleagues:

Sponsored Ads