Error dialogs seem to rarely best their progenitors from decades ago. In fact, often the modern counterparts are worse—either they offer misleading oversimplifications or they are little more than graphical wrappers for some obscure error code optionally coupled with some half-baked developers’ notes. Obviously, redesigning error dialogs won’t automatically fix this problem, but other oversights couple therewith to plague the user experience with something goes awry.
First, cramming all the information into one paragraph tends to encourage content blindness. I have mindlessly clicked on dialogs without reading them simply because what information they might have held looked like too much work to parse, and I’m unusually cautions about clicking. The first change, then, is to separate the information:
- The top section contains a simple—but, critically, still accurate—explanation of the error that occurred.
- The middle contains details about exactly what caused the error, generally in greater technical detail than the top.
- The bottom section suggests solutions for the error. If there are none, explain why, if solutions are known, list them, and if there isn’t enough information to tell, admit that. Developers nearly always have access to a wealth of information about why things go wrong, so the last case needn’t happen often.
The most significant change is in the bottom section of the box. For solutions that can be handled automatically (such as converting formats, changing settings, loading a file, etc.), their explanations are marked as clickable, which then performs their respective suggestions.
A quick mock-up to demonstrate the design follows:
Nathan Bell | 12-Jun-08 at 4:29 pm | Permalink
I’m curious, are you advocating for modal error boxes, or is this just a suggestion when you absolute have to have a modal box? Are there even such cases?
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?
ichthyo | 21-Jun-08 at 8:25 am | Permalink
Hi, just saw your blog entry and couldn’t resist to post an answer “from the other side of the brick wall”. (please note the slightly ironic tone)
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.
Clay Barnes | 25-Aug-08 at 4:25 pm | Permalink
@Nathan Bell: I would say that an always-connected environment would be best leveraged by providing links to a wiki page whose URL is derived from the cause of the error.
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.
Clay Barnes | 30-Aug-08 at 7:19 am | Permalink
@ichthyo: I admit that in the post I severely minimized the concerns you raise. However, I’m not convinced that errors are intrinsically the apocalyptic scenario we often let them become. For example, my user-wiki-linked idea from my reply to Nathan Bell is one example of how limitations on a programmer’s/team’s time could be circumvented, so long as a minimum framework is initially established. Perhaps my “solving the problem buttons” part of the bottom section isn’t realistic for true errors, but user-contributed advice on recovery can be an excellent resource to replace that.
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.