I think I will post a follow-up entry to this at some point to expand on the wiki/community/time-shifted refinement of error-dialogs and bug reporting.

At that point, users could report bugs (let’s be honest, the traditional system for bug reporting is asking more than most users are willing to invest), and because they would also have many other user’s observations, they needn’t repeat the same data over and over—just add/clarify the new details they may have discovered. Further, the developers could easily interject any hints, tips, patches, or tools pertaining to the problem that they have.

A lot of the content could be extracted from the box I sketched and put on the page, or as an alternative, special sub-sections of the wiki could be the *source* for the error text! A strong community using some software could easily best nearly any pure programming team in explaining causes/effects/solutions to errors.

Everything you write is desirable, indeed. But, simply put, you are overlooking the nature of the situation which causes the error box to appear.

First, let us distinguish. There are two quite different situations: (a) an alert. (b) a error box. In Situation (a) I (the coder) am in control. I detect some deficiency in my program code and need to alert or query some information from the user. But these usually aren’t the problem, because in any halfway decent application, the alert cases are handled already ok and somewhat in the manner you describe above. For example “no printer selected. On your system are the following bla bla bla… please select one from the list below:”

The problem is situation (b). If this situation happens, you can tell with 100% certainity that I (the programmer) *lost* the control about the situation. I am no longer in charge, I couldn’t prevent it, because my predictions were wrong and my precautions failed. Now, because I am a overly precautions person (otherwise I wouldn’t have survived in the “software factory”), I built a *generic* mechanism into my program to re-gain control on a higher level, trying to abort and cut away the corrupted data as far as possible. So, you can tell for sure, that the text given in the error message visible to the user is always a decoy. At maximum it could run as follows “something went wrong. We don’t know what. We see MrmWrmpf is mxwdsxy+fac(2)-10*50+1 and is should be &wx6ed[3]->XXZZ. We don’t know why. We prevented the Application to crash but we don’t know if our attempt was successful. Sorry. Shit happens.”

Now, if any normal decent feeling person sees such a message, s(he) will be frightened to death and loose all trust into the program, the product or computers in general. Thus, if there is anyone caring for the user or the “customer relationship” in this development project, this person will prevent by all means that the programmers create honest error messages. Consequently, we programmers are all trained in cleverly inventing a wording which gives the impression that everything is harmless and under control and which invokes the feeling in the user, that s(he) has done something terribly wrong.

Here finally, I should add two clarifications.
1) when a error situation arises, the developer was not “able” to detect/prevent/foresee it. The emphasis is on the ability. In most cases this means, there wasn’t the time and/or the budget to do so. Also, in many cases it is due to a shortcoming of the general design, that at this given point we can’t “see” and prevent what’s going on.
2) there is a more subtle architectural problem involved. Error handling is always a so called “croscutting concern”. It is so by its own nature. It’s always related to things we can’t care for right here, to data we don’t have at hand right here. Security is another such concern. If we would try to solve error handling, security, transaction management first class perfect “on location”, our code would be messed up to such a degree, that it would be unmaintainable with respect to the primary goals and concerns. Of course, there are a lot of different possible half-way solutions to deal with all those problems — and the price to pay for this “half-way-ness” are the messy error messages we all love so well.

In the wild, my ‘favorite’ modal errors box experiences are with those that contain hyperlinks to more information, or at the very least are copy and pastable into Google. What would an error dialog box look like if it assumed a persistent Internet connection? How would that compare to a screen-long modal error box?