Lists Home |
Date Index |
On Sat, 2004-04-10 at 06:07, Bryce K. Nielsen wrote:
> ----- Original Message -----
> From: "Henrik Martensson" <firstname.lastname@example.org>
> > The purpose of XML is to enable as much automation as possible. Using a
> > text editor to write XML documents is missing the point of using XML in
> > the first place!
> Actually, a lot of us feel the exact opposite. I *hate* visual, GUI editors
> for XML. Just as I hate GUI editors for HTML. While in some cases GUI
> editors can be more fast, but once you need to code out-of-the-box it can
> get extremely frustrating. I'm like Amelia, I end up shouting at the
In the environments where I work, things come to a crashing halt when
someone has coded out-of-the-box. I realize that doing a bit of creative
tagging is not always a disaster, but in industrial settings, it often
is. It is as if someone at an assembly line suddenly decided to make a
piece of work just a little bit off spec. Somewhere, further down the
line, the piece just isn't going to fit.
> application "Get out of my way! Let me do what I want to do!" and then I
> just open the document Notepad.exe and I have complete freedom.
I do understand the point. You, Amelia, and everyone else certainly have
the right to your own personal preferences.
I am interested in exactly why people think that editors like XMetaL and
Publisher are frustrating. It hardly the typing speed, because the
editors do keep up even with fast typists. These editors can be
configured to provide a lot of help to authors unfamiliar with a
particular auhoring environment, but you can also have a slimmed down
bare bones system if you want to.
When I talk to (other) writers, they frequently have the same criticisms
of XML based authoring systems:
* Tags are visible in the editor, and they don't want to see
* They can't see what the final output will look like.
* The DTD does not contain the markup structures they need.
They feel the editing environment is too constraining.
* The system is slow.
The first two points are quite different from the opinions voiced here.
Nobody seems bothered by visible tags, though we may have different
ideas of how to present them. Nor have anyone said that it is a problem
not knowing what the final output will be.
We'll focus on the last two points.
When analyzed more closely, authors who complain about undue constraints
fall into three categories (well, most of them do):
* Those that want to add procedural markup, like bold text, italics,
and so on.
* Those that consistently use the wrong tags, and therefore paint
themselves into corners.
* Those that have a genuine complaint: they need to do something that
the system does not allow them to.
The documents aren't supposed to contain procedural markup. So
complaining about it being missing is just not a valid complaint. Not
being able to distinguish between an ordered list and a procedure is not
a systems problem either. A rough guess is that about 1-5% fall into the
genuine complaint group.
This does not mean that the other complaints should be dismissed out of
hand, of course. There may well be a genuine problem, it is just that it
is not the thing the author is complaining about.
When authors complain of a slow editing environment this can usually be
traced to one of the following causes:
* The editor really is slow, usually due to network problems or
* The editor is slow due to files being too large. (Editing an
18 MB XML document in XMetaL is possible, but not practical.)
* The DMS they use is slow, creating the perception that the editor
These problems are usually quite easy to identify, though actually doing
something about them is another matter.
A number of things strike me:
* What the authors I come into contact with and the people in this
thread both dislike is loss of control
* In the case of the authors, the loss of control is mostly perceived.
If they had that bold tag they want in the DTD, their writing rules
would still forbid them to actually use it. If they used the tags
they are supposed to use, they would be able to structure the
documents the way they want.
What the authors are supposed to do, is to focus on structure,
disposition, explaining things clearly, writing in reusable chunks, etc.
Many of them cannot do that, because doing so requires training, and the
companies they work for don't want to spring the money necessary for
that. Technical authors are very low in the pecking order. Usually the
first to get short changed, and the last to get any perks.
Most technical writers have neither formal, nor informal, training for
their job. Most that I have met have an engineering or programming
background, or come from advertising firms, or something even more
unrelated to technical writing. As a result, only those few that really
have a talent for, and interest in, writing technical documents learn
how to write good manuals. Most do work that is far below their true
When an author cannot write well, whatever the reason, his or her self
esteem has to be tied to something else. Quite often, the "something
else" is the visual layout in a document window. In other words, if the
content is no good, it can at least look good.
When the author eventually discovers that the tag abuse that made the
document look good on screen created a complete disaster in print, the
result is confusion and shock. A blow to the self esteem. Quite
naturally, there is a tendency to get angry, and to blame the system.
(And sometimes the author is right. There are a lot of awful authoring
systems over there.)
For the people on this list, self esteem is just as important as it is
to the average author, perhaps more. Many of you are probably quite a
bit like me, investing a ridiculous (and quite dangerous) amount of self
esteem and pride into your work.
Wanting to write tags yourself, even though software can do it more
efficiently, is, I believe, partly because of the self esteem tied to
the knowledge of XML markup. Another important factor, I would guess, is
the nature of the work. Most of you develop XML based systems of one
sort or another. When I do that, I often find it practical to view and
edit XML in a text editor.
To me this is quite distinct from editing XML in a production
environment, and that is due to my background as a technical writer.
Until not too long ago, I wasn't especially enamored by code completion
and templating systems in IDEs. I was afraid that if I used them, my
skills as a programmer would atrophy. Well, I do a lot more programming
nowadays than I used to, and you know what, I changed my mind. Now I
gladly accept any help I can get from my IDE. Not only did my
programming skills not atrophy, I am a better programmer than I ever
was. (Though this does not necessarily mean all that much.)
> I think a lot of XML developers come from an HTML background, and this
> difference exists in HTML editors too. Those that try to do everything for
> you like Dreamweaver or FrontPage, and those that are just text-editors like
> Homesite. Some obviously prefer one over the other. To each his own.
I don't like Dreamweaver and Frontpage much, though that is because they
produce crummy markup, not because of their user interfaces.
> > I do not think we will come to an agreement in this thread.
> I disagree ;-)
Ok. I happily concede the point. :-)
> We can come to an agreement, that being that each XML user will have their
> own preferences on how they prefer editing their documents, just like HTML
> editors. I HATE GUI editors, I've tried all the apps you've refered and feel
> they're overbloated and I want a simple tool that lets me do what I want
> (which was why, btw, I create xmlHack). Others though, like yourself, prefer
> apps that automate facets of XML.
I do agree that there is a need for different viewpoints, and different
ways to do things.
> I can't stand that, I prefer free form and no one's going to change my mind.
> And visa-versa for you. Nothing we say will change your mind. And honestly,
> I don't want to. Use the tool that's the most efficient for you. However, I
> will ask you to not try to convince others that "text-editors" are pointless
> and archaic. For a lot of XML users, they're just what the doctor ordered.
I won't, particularly since I sometimes use those kinds of editors
However, I do believe that for most writers, in most situations, editors
like XMetaL do add a great deal of value. I also believe that for an XML
editor to gain widespread popularity, i.e beyond XML developers, it has
to provide more than a "text-editor" can do.