[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: DOCBOOK-APPS: best tool for docbook?
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 <firstname.lastname@example.org>
Powered by eList eXpress LLC