The Interface Hall of Shame

This site is an absolute must-read (a term I do not use lightly) for anyone involved in the design of GUIs, be it as software developers, interface designers, managers involved in the decision process, product managers, ...

Currently, the site is available at http://homepage.mac.com/bradster/iarchitect/shame.htm^e; however, it is my impression that this is a resurrection of the original site that I encountered in the late nineties. The site is severely out-of-date (last update around 2000?), but gives principles that are still valid—and discusses some problems that still (2009) exist without change in e.g. Windows and Lotus Notes. Importantly, even now it is the site on GUIs most worthy of readers’ attention that I am aware of.

A few issues where the site is not quite up to par:

1. It blames many decisions on us “geeks” that in my experience usually come from management. Further, it overlooks that many of the errors that are due to poor decisions from the geeks, have their root in external circumstances, e.g. a too tight dead-line. (The mistake is still a mistake, obviously, but the blame does not always reside where it appears to reside—and if unknowing users blame the developers instead of the managers, this can conceivably have negative consequences.)

   The claim that

   This terminology underscores Lotus Notes as an application clearly designed by geeks to be used by geeks. Unfortunately, those responsible for purchasing Notes as a corporate e-mail solution must be geeks as well.

   (http://homepage.mac.com/bradster/iarchitect/lotus.htm^e)

   strikes me as particularly odd: Every geek I have ever heard express an opinion on Notes has hated it; whereas it has typically been a few highly influential business graduates who have forced Notes upon the rest of the employees (in those Notes-using companies I have been familiar with). As a geek, I consider the accusation border-line offensive—true geeks hate Lotus Notes!

2. A lack of technical insight is displayed by an aversion towards technical details in error messages. An error message, no doubt, should contain information that makes as much sense as possible to the user of the application; however, I still recommend to additionally put in technical details in those cases where it can be relevant (this should be a minority). If an error is of the kind that a hot-line needs to be contacted or a bug reported to a developer this extra information can be of vital importance. Overall, most applications tend to err on the side of too little information—I have often seen idiocies like “File not found!” without a mention of what file could not be found... (Cf. my discussion of error messages.)

3. Odd uses of “programming environment” where, from context, either “run-time environment” or “program” was meant—the work of the programming environment is long over by the time an application is running on the computer of an end-user, and e.g. “error message generated by the programming environment” means something else than the author(s) probably intended.

4. A certain naivete about how much effort is needed to make seemingly small adaptions and how much risk can result from them: Adding one line of code may seem to be something that can be done in ten seconds; however, there is thinking on special cases, possibly a compile cycle, basic testing of the change, possibly entries in a time log or a change in an issue-tracking tool to make, a commit for the version-control system, updating of documentation, possible complications of various kinds, etc., to consider. In all, having a one-line change entirely completed is often more of a ten minute task for a developer who is conscientious, follows all rules imposed from above, and makes sure that he does not introduce two new bugs when fixing the old. In complicated cases, in particular for very junior developers, the time needed can be considerably longer. Add to this that other people may incur additional work too, most notably testers. (And this obviously assuming that everything went well: Every change brings a risk of a new bug with it; and should one occur, the total effort can easily land yet an order higher.)

   The simple truth is: In the end phases of a project, it is sometimes best to postpone a trivial looking change of a newly discovered problem to the next release. (Note that it is not unusual for a veritable hail storm of such changes to occur. We do not talk 10 minutes times 1, but often 10 minutes times 20 times the number of developers. With a dead-line close by, the resources for this extra work are not always there.) This, by the way, is another good argument for the best practice of short release cycles. Also note that if another best practice—early user feedback—is followed, such problems would not be predominantly discovered in the end phases in the first place.