GUI [Anti]Patterns and Safety-Critical Systems
Testing and debugging the DLL involved running both clients, which under Visual Studio is not immediate: you can run one (the startup project) with the usual start button, but you have to manually select the other project in solution explorer, right-click, choose "debug" and then "start new instance". No big deal, except that I kept clicking on the wrong menu item ("Add" instead of "Debug"). I had to pay a lot of attention to avoid this mistake, but anyway, in a couple of hours I made something like 10 mistakes or so (to the general amusement :-).
As I said, no big deal, because Visual Studio is hardly a safety-critical application. However, in the past few days, I've been exchanging a few ideas on how to improve the GUI of a safety-critical application, and that episode came back to my mind. Why was I choosing the wrong item? Was there anything to be learned? There are at least two reasonable explanations:
1) I'm rather dumb, and I must be kept away from safety-critical applications.
2) Something in the design of that pop-up menu was misleading.
Now, (1) is a serious possibility :-). To quote Edsger Dijkstra in Programming Considered as a Human Activity, "I have only a very small head and must live with it". But (2) is also a possibility worth exploring.
So, here is the suspect menu, in its compact and expanded form:
Now, I'm not the first to think about GUI and safety-critical systems. There is quite some literature about it, including some (small) pattern language. An interesting paper is Patterns for Designing Safety-Critical Interactive Systems by Mahemoff and Hussey (I'm providing a link to citeseer cache, as the original link seems to be broken).
Within that paper, the pattern that seems most relevant for the situation at hand is "Intended Action":
Problem: How can we enhance assurance that a user's action matches their intention?
Just what we need! Unfortunately the solution part is not that helpful:
Solution: Arrange the user interface so that affordances are provided which reduce the likelihood that an error will occur when the user executes a task.
The examples provided are quite good (especially if you're familiar with Donald Norman's works), but they do not immediately apply to a simple pop-up menu.
However, given a pattern we can easily form an anti-pattern. In this case, the anti-pattern would be:
Arrange the user interface so that affordances are provided which increase the likelihood that an error will occur when the user executes a task.
Is there anything like that in the menu above? Well, sure there is. Note how many items have a distinct visual clue on the left, relating the item to a familiar (and distinct) icon in the menu bar. This is a good application of the pattern above.
Also, notice how both Add and Debug provide an identical visual clue on the right, to indicate that they can be expanded. My small head was obviously confused by the two identical clues, and I was clicking on the wrong item (probably because I was visually scanning for a picture, not for text; that's the "rather dumb" part, I suppose :-). This is an instance of the antipattern.
Interestingly, the icons on the left and on the right seem to have the same purpose: they indicate what it's going to happen if you click on the item. The icon on the left represents the action that will be started. The icon on the right indicates that a sub-menu will be opened.
Note, however, that at a conceptual level they serve a remarkably different purpose: the icon on the left is concerned with application-level functionality, the icon on the right is hinting at navigational-level functionality. That's why the icons on the left are different, while the icons on the right (if present) are identical (an arrow), and may lead to confusion (I want to stress the idea that it's no big deal for Visual Studio: I'm just using a real-world example to talk about issues that would be relevant in the design of a critical-safety GUI).
Now, can we fix that? Well, sure. A simple fix would be to keep the arrow on the right, but still add an icon to the left (e.g. the icon of the first item in the sub-menu, if any). This will give a clue on what's below, and I'd surely click on the entry that looks like the button I've just clicked on the toolbar.
An alternative idea would be to change the indication on the right (e.g. by placing the icon of the first sub-menu item right before or after the arrow), although this would conflict with the common Windows paradigm (which wasn't designed for safety-critical applications anyway).
Yet another could be changing the arrow to a somewhat less eye-catching shape. Probably, you can come up with a few more strategies. As usual, in real-world safety-critical systems some (well-designed) experiments would be needed to determine the magnitude of the problem and the efficacy of every candidate solution.
A final note: there are quite a few interesting point in that paper on safety-critical systems. You will recognize the centrality of contextual design, as safety-critical systems may have to compromise on other important aspects (e.g. user productivity). Bainbridge's ironies of automation are also extremely interesting, and you may want to spend a few minutes pondering on them :-).
Natural Form Filler
Here is one of the critical portions (from the arrival record):
and the even worse copy in the departure record:
The biggest issue is that when you initially look at the form, you may (or may not) see the "1. Family Name" label, as it is placed too far from the slots you've to fill (and too close to the thick horizontal line above), while the label "2. First(Given) Name" is just where you would expect the explanation for the first field. Assuming you see the right label, your eyes tend to move right to this part of the form:
Where you don't even have the smallest visual clue to tell you that the birth data has to be written under, and not above, the label itself. The problem is even worse in the departure record, because that's what you see:
The short line seems to indicate that the previous field has finished and a new one started, but again, you have to write your birth date under, not above, the label. Also, the family name label is slightly closer to the thick line than it is in the arrival record.
The problem is obviously easy to fix. Give the right proximity between fields and labels. Avoid those misleading vertical lines. Use some strong visual clue to indicate the end of a field.
Here is a trivial example:
This is not necessarily the best, but is a significant step forward. To make it truly better, a more radical change would be necessary: put the label under the field, not on top of the field. If you put them under, you can make them very close to the field. If you put them above, you have to make them distant in order to leave enough space to actually write something.
As usual, there is a lot software designers can learn by looking around. If you like this kind of stuff, I can warmly suggest "The Design of Everyday Things" from Donald Norman, a nice book to read for everyone involved in designing... anything :-).