Re: Why WYSIWYG for XML???

["Mark Baker" <listsub -at- analecta -dot- com>]

Bill Lawrence asks:


> But why is everyone so insistent on WYSIWYG
> for technical documents?

At the recent Content Management Strategies Conference I heard yet another
speaker state that one of their system requirements was that the authoring
solution by "No harder to use than a word processor" and I wrote down in my
notebook, "What's so easy about word processing?"

Certainly from the litany of Word woes and Frame frustrations that appear on
this list it would not seem that word processors and DTP applications are
all that easy to use. I suggest that the minimum standard for any new
approach to developing information should be that it has to be significantly
easier than word processing and DTP.

But I think the biggest reason that people insist on WYSIWYG XML is that
they believe in fairies. They want greater productivity and improved quality
but they are not willing to do the hard work required to really change their
processes. Along come the people selling XML pixie dust, and people hope
that by sprinkling XML over their existing process that productivity and
quality will magically improve thanks to the mystical properties of the
angle bracket. Given that they are not really changing from a word
processing / DTP paradigm, it is not surprising that they continue to want
word processing / DTP interfaces.

When people say that they have decided to move to XML I wince, because that
phrase, by itself, is about as meaningful as saying you are moving to
binary. The real issue is whether you want an monolithic single step
information development process (which is the real implication of WYSIWYG)
or if you want to divide the information development process up into several
discrete stages. There are several different reasons for doing the latter,
but whatever the reasons, such a strategy benefits from having a
standardized human-readable syntax to communicate information between the
stages of the development process. That's where XML comes in handy.

But people need to be looking at the process change, not the format change.
Switching processes may pay big dividends. Switching formats without
changing processes gets you nowhere. A switch from a monolithic to a staged
process requires significant process design work, significant job role
redefinition, and significant staff training. Without it, people will
naturally cling to the familiar.

If this transformation of process is undertaken, the role of the author
should become easier and their tools should become simpler. However, two
factors commonly get in the way:

1. Lack of proper training in the new role of creating multi-use content
elements rather than documents. People end up fighting the system because
they don't understand how their jobs have changed.

2. Lack of lucid markup design, resulting in markup that gets in the way of
the authoring effort even more than formatting used to do. For more in this
problem see my recent CMS Watch article on Lucid markup design.
(http://www.cmswatch.com/Features/OpinionWatch/FeaturedOpinion/?feature_id=1
01)
---
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.