RE: DOCBOOK-APPS: best tool for docbook?

["M. Wroth" <mark@astrid.upland.ca.us>]

Hear, hear!

I'm not sure I want to claim to be either a writer or a programmer, but I 
think Denis has put his finger on the key issue.  None of the tools I've 
seen do a good job of hiding the irrelevant (to the author) mechanics of 
SGML/XML and the processing toolchain from the author.

By that I do not mean "hiding the markup", although the right way to 
display this information may not be the markup tags.  In DocBook (and other 
XML/SGML) the selection of semantic tags for regions of text is part of 
what the author should be considering.

I haven't found any better tools than Emacs/PSGML -- although that may be 
partially a function of the fact that I'm pretty comfortable with Emacs.

(I will comment, BTW, that current versions of Emacs are much easier for 
beginners than the Emacs I learned on was.  The addition of menus and pop 
up requesters has helped a lot.)

But I'm not sure I know what a good GUI design would look like.  There has 
been a lot of usability work done on WYSIWYG word processors, some of which 
may be helpful here.  But the paradigm is different for marked up text, and 
I'm not even sure I know what *my* mental model for this is, much less what 
a common mental model would be, or how to implement that model in a way 
that is intuitive for an author.

At 02:54 PM 8/26/01 -0400, Bradford, Denis wrote:
>If a writer can chime in: the issue for me anyway is not so much WYSIWYG (I
>do get the markup paradigm) as good GUI design. There are so many pieces to
>deal with (entities, IDs, etc.) that it becomes a little like herding
>bumblebees to manage them all. What the masses (like me) need in an editor
>is a tool that overcomes the limitations of serial text navigation. That's
>what GUIs are for, not just to prettify things.
>
>To put it another way, the point is not to hide the document structure, but
>to reduce the complexity of the authoring process. For example, Emacs is
>probably powerful enough to provide everything an editor needs if you know
>about modes and such, but its interface is so damn complicated that, as you
>say, it takes more effort to use the tool than to write content. At least
>for non-programmers.

Mark B. Wroth
<mark@astrid.upland.ca.us>