Re: Whither book "Developing Windows Error Messages"

[Chuck Martin <cwmartin -at- US -dot- ORACLE -dot- COM>]

Lani Hardage wrote:
>
> I wouldn't do away with all error messages. Many of them save you from
> yourself, as in, "Do you really want to blow away all the work you just did,
> or did you mean to hit the other button?"
I disagree. Such confirmations really say "We, the programmers, think
you are too dumb to know what you are doing, so are you sure you wanted
to click that button?" Treating users like idiots is not a good
approach. Given a clear software interface, user really do, in general,
know what they want to do.

For example, that's what the Windows Recycle Bin and the Macintosh Trash
are for. They are buffers designed to let users recover from those very
mistakes--without throwing an anooying message box in front of the user
*every* time a file is deleted.

>
> There are also useful error messages, such as, "The foo-bar cannot be
> retrieved, because none have been created." How else could you convey this
> information? I presume this book would teach you to offer a fix, such as,
> "Would you like to create a foo-bar?"
In the vast majority of cases, that information can be conveyed in the
software interface. For example, an empty list box labelled "Existing
foo-bars. Select one, then click Edit, or click New to creat a new
foor-bar."

>
> Programmers tend to write these error messages because the messages are
> often embedded in source code, and they don't want non-programmer types
> mucking with the source code. Also, they don't want to have to teach us the
> code you need to wrap error messages in. Finally, some error messages are
> tied in withthe error-handling code, so it isn't worker-efficient to break
> it out into two people's tasks.
I can't count the times I've heard that argument, and it just doesn't
hold water. The message here from programmers is "We're gods and you are
not worthy to even look at our code." It doens't take much to understand
how to write or edit error messages in code without making other,
unintended changes. Besides, in most cases nowadays, error mesages are
kept in a separate file, which makes for better internationalized code.
If a company isists on bad software design full of error mesages, the
*least* that can be done is that a programmer's draft of error messages
gets printed out and handed to a technical communicator to edit for
clarity, context, and consistency, and that hardcopy gets handed back to
the programmers with a mandate to make those changes.

>
> Chuck Martin wrote:
>
> > I have several issues with this, without even reading the book--and I'm
> > not sure I even want to now.
> >
> > First, it's [sic] claimed target audience is programmers. Why, oh why, do
> > the
> > authors and publishers want to perpetuate the myth that programmers
> > should be the ones to write error messages? While it would be nice for
> > programmers to learn to communicate effectively with a non-technical
> > audience, isn't that what we, as technical communicators, are trained to
> > do?
> >
> > Second (and this is a more root issue), I'm a firm believer that error
> > messages are bad. Bad, bad, bad. ...

--
Chuck Martin
Principal Technical Writer, Oracle Developer
Tools Division, Oracle Corporation

cwmartin"at"us.oracle.com

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=