Customer Reviews

Developing Windows Error Messages: Error Messages that Communicate

5 star:		(3)
4 star:		(2)
3 star:		(2)
2 star:		(1)
1 star:		(0)

 

 

Ben's book is well-written and well-edited and provides a number of useful ideas on how to write effective error handlers and error messages in the Windows environment. It's focus may seem strange to nonprogrammers, but programmers appreciate this sort of guidance on details.

However, Ben does repeat some saws or maxims which need to be deconstructed.

One is that at one time, error messages were overly terse because "there was not enough storage" to make them useful.

I find this disingenuous, because the dreamtime to which Ben is referring to is probably the early 1980s. In the early 1980s, I was as a former IBM 1401 programmer (whose first machine ten years prior had 8000 characters of storage) in awe of the possibilities of the primitive disk and tape systems then available.

On the 1401 I had developed a system which used an "overlay" and a supplemental manual procedure to provide a user with fully expounded error messages in English, and by the early 1980s, providing my users with English error messages was not a problem.

The idea that at any time "we are limited by the gear available" is to me a confession that a certain need is not important enough to warrant our time. Basically, the need of users for error messages has always been triaged and continues to be triaged in an unconscious binary opposition between the "serious" and MALE tasks of programming, and the "not serious" FEMALE task of communication. To me the first mistake was to divide these tasks.

Another old saw Ben repeats is that "programmers", in inverse proportion to their skill level or interest in being "programmers" do not like to write, or cannot write.

This saw exists in a logical dependence on an idea from outside programming which is that there is such a thing as a content-free "skill in communication". Although a convenient corporate reification, useful for example in getting rid of racial minorities, women, and older employees on the basis that they are mistreated because of a generalized lack of "communications skills", the very idea that we can speak of communication without discussing content, or for that matter simple morality, is nonsense.

"Poor communicator" may be a true generalization as applied to the actual population of programmers in the United States. However, it is belied by a maxim of hero computer scientist Edsger Dijsktra, which is that programming ability is indicated by command of the language.

To the extent that programmers write overly terse error messages they may actually be, while statistically representative of American programmers considered highly qualified, less well-qualified than they could be.

This is because the only evidence we have that the programmer understands his system is something outside code.

Ben Ezzell himself shows he's qualified by not only writing good examples of error messages but also by being aware of what the user probably needs. He does so as a programmer who can code, and it is a false humility of his to say that programming skill has nothing to do with communications skill.

Managers love to give programmers books such as Who Moved my Cheese? and The Elements of Style, probably because these books rigorously exclude the content of the programmer's work from consideration. This may be useful in some cases but basically it is an attempt to deprofessionalize, for it denies that the programmer has learned anything worthwhile.

The managerial saw is that by definition "mere programmers" do not know enough to communicate with users and require by definition an interface consisting of people who do things like review, or actually compose, error messages. But inside the corporation, resources are allocated by non-market means despite the commitment to the free market, and the practical result is that most corporate employees seek first to avoid blame and are therefore not likely to compose forceful and hard-hitting error messages because in the corporation, the messenger is killed for bad news.

I am not dismissing the need for people to perhaps specialise in technical writing or even the composition of error messages...especially for international systems. It would almost be too much to expect programmers to know multiple human languages. What I don't like is the ideology implicit in saying that we must cultivate a content free communications style. I like Ben's book because it is ABOUT both programming and communicating.

The genuine quality of this book, together with its genuine aporias, indicates a need for a definition, outside corporate hegemony, of programming. This definition is needed because if programming is implicitly defined ONLY as MIS programming, it becomes impossible to develop effective systems for the public good...as evidenced by the real problems government and not for profits have in implementing systems; because of omnipresent cost considerations, many such organizations are forced to use off-the-shelf packages which encapsulate (at a deep level) assumptions valid only for private, for profit businesses in what are called "business rules."

A critical theory would define programming, not just writing error messages or documentation, as writing and not mathematical, while at the same time realizing that many practitioners seriously underestimate the applied mathematics of programming. In the present arrangements in the US, programming is considered mathematical and numerical in some sense, thereby excluding many people who could make a contribution, while in another sense, any form of real mathematics and real logic is excluded at the critical point in the development of many systems, usually when cost constraints can be used to justify hand-waving.

If I understood what Claude Levi-Strauss was talking about in expounding a way to read a myth against its own grain rather than literally, I would be able to conclude that American programming praxis is a form of systematically misreading an Enlightenment myth. This would help me to understand why such genuine talent and ability such as Ben's is on display in books from publishers like O'Reilly whereas in practice error messages STILL confuse genuine end users.

This book contains very little meat for my taste. I can't believe that, as a book devoted to Windows error messages, it does not even mention the Windows NT Event Log anywhere! I'm returning the book since I can't find much in the book that adds to my experience.

Perhaps new programmers can learn a thing or two from this book such as the three elements of good error messages. But as an experienced developer, I'm totally disappointed with this book and would not recommend it to any of my peers.

I have finished reading all the sections of this book that I will read, and am preparing to find a new home for it. Overall, I am disappointed with this book, considering the publisher and price paid for it. Most likely, this expensive book is getting returned.

If you have no experience with creating suitable user interfaces for error messages and/or error handling, this book is a good place to start. It provides solid information on when and how to interrupt the user for various error types, and describes the various error types extensively. However, as an experienced programmer, I was looking for specific and new information about generating error messages. I really didn't find anything that was of any use to me that was related solely to error messages. Don't get me wrong - there is good information in this book, but most of it is based upon general, common sense ideas about user interfaces and error handling.

The thing that annoyed me the most was that the writing was too verbose and the book too long for the limited content found in it. I frequently found myself skipping over the personal vignettes looking for nuggets of useful information, and the "humor" was artificial and contrived - isn't this supposed to be a professional volume? The content in this book would be more useful and accessible if it were distilled and placed as a couple of chapters in a more general introduction to user interfaces book.

I would agree with other comments that this book is more philosophical than technical, but I think that is a good thing. When planning a program the error handling side should be more thoroughly planned, and this book helps with just that. I found much of the book obvious, and could flip through 5 or so pages at a time, but the bits that are not so obvious are worth searching for.

If programs are written using the style of error messages and/or the error message handling process suggested within this book I feel that the user term "User Friendly" (at least in relation to errors) would actually be deserved. For instance, how many times have you come across an error that only has one action that you can take "OK"? Is it okay that the error happened? Is it okay that you can't do what you were trying to do?

Therefore I would say that this book holds much more value to the project manager/project leader/planners than programmers.

Much of what is spoken about is not OS specific (besides a bit of code). It seems that it is directly aimed at Windows 95, which is why there is no talk of NT error logs.

I found the supplied code (2 DLLs) to be a bit old but it was a simple enough to use it as a template and build on them. The dialogs within the sample code are quite user and programmer friendly and did not need altering. Using code I already had, I added database error lookup/logging, screen and system capturing, NT Event Logging, email support and COM Interface within a day. HOWEVER I feel that the supplied code is of little value to any programmer who is not planning on altering the code in some way, so it may not be much use if you don't know C++.

Overall, I recommend this book to anyone trying to improve their error message reporting. The book includes a CD containing a first rate message reporting DLL. This code is itself worth the price of the book.

The author's writing style is somewhat verbose for my tastes, and is filled with irrelevant and pointless footnotes and personal asides. Thanks to the excellent formatting and editing of O'Reilly books though, this doesn't seem to get in the way of reading the book.

The book covers an interesting and previously un-covered topic. Depending on your experience it may prove to have some good ideas too. There's something to pick other than ideas too--it shows how to use the "html browser" control, which if you haven't yet found out how to from somewhere else, is helpful to learn from here.

At the same time, there are shortcomings. An example of a rather minor one is questionable opinions presented as indubitable truths: "html-based docs are always nicer than rtf-based ones." (Really? W/o looking at the file extension, how'd one tell the difference? ) At times I had a feeling that wrong words were used to express something. More importantly, the book is very wordy--I constantly catch myself skipping lines impatiently and in irritation. The book could have been half the size (and definitely half the price.) Finally, and most importantly, the book's most prominent failing is a gush of artificial, absolutely pathetic, never-successful and always-nauseating attempts at humour--the typical MSPress-style of phony writing. I have a funny feeling about that because in the past I'd read quite a few O'Reilly unix books and there was none of it there. I'd also read another, earlier book by the same author--there was none of it either. Who makes them write like that all of a sudden? My (conspiracy <g>) theory is, it's MS's propaganda department. If you know the truth--send me a note, I _am_ curious.

I so far has refrained from highlighting anything in this book. I have a premonition: I'll send it back. After all: speak English, dudes. (That is, unless you purposefully write for imbeciles, if you do--then you're ok.)

The book provides some clues on how errors should be considered. It spends a lot of time describing the current situation in a very verbose style. OK that's fun but not very instructive (I mean, we all know half the messages are stupid, unfounded, incomprehensible, etc.). This beeing said I would recommend the book for the same reason....

Great book, it read like a satire. This is the first book I have read dedicated to how to write error messages for a particular OS. I guess when your OS is full of cryptic hogwash, investigation reveals that the OS should be discarded altogether. I see a new usenet group forming: alt.badOS.poor.lowest_common_denominator.

I will keep the book as a paean to Bill Gates. Otherwise an average written book by an otherwise great publisher.