This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
RE: best tool for docbook?
- To: "Bradford, Denis" <denisb at rational dot com>, docbook-apps at lists dot oasis-open dot org
- Subject: RE: DOCBOOK-APPS: best tool for docbook?
- From: "M. Wroth" <mark at astrid dot upland dot ca dot us>
- Date: Sun, 26 Aug 2001 13:54:47 -0700
- List-Id: <docbook-apps.lists.oasis-open.org>
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>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>