David Burrowes' Blog

This week I ran into several references to "grand unification" in software. An internal project has the name "Grand Unified (thingie)", I was reading some about GRUB (GRand Unified Bootloader). And, amusingly, as I came to write this blog entry I noticed a very new entry on blogs.sun.com called "Why not a grand unified garbage collector?"

As a developer, I love all these things. Solving many problems with one solution is often efficient, reliable and satisfying.

As a UI designer, however, I cringe when I think of this.

As an extreme, I was joking with a coworker involved with an installer project that we really just dispense with all our software and only use installers. You want to add some text to your StarOffice document? Just run the "New Text" installer ("Welcome to the New Text Installer, I agree to the License agreement, pick the document that I want to install the text into, specify the text, click "install", get the summary report (don't show me the readme) and quit). Makes the user experience very consistent. You get the same interface for everything.

Of course, that would actually be a terrible experience. While that is extreme, there's no doubt that all of us in the software field are inclined towards the conceptual elegance of unifying things.

A moderately extreme example is the Newton from the early 90's, which was basically trying to be equivalent to a desktop computer of sorts, but in a portable form. It got trounced, of course, by the Palm Pilot. While the pilot did that partially on price and size, I think it also partially did that by removing the sense that it was a "do anything" device and instead focused on doing PDA kinds of tasks well. It was, fundamentally, easier to understand and thus use.

A much less obvious example here is the JTable component which is part of Swing. This seeks to serve all tabluar needs. This seems like a good thing. As a developer you learn one class (or, one suite of classes) and you can create a spreadsheet, a multi-columned list or (if a tree is added to it) a hierarchical list. The trouble here is that when you look at the user experience of these different interfaces, they actually have slightly different requirements. A spreadsheet-like interface may legitimately allow individual cells to be selected and modified independently of all others. In contrast, in a multi-columned list each row is a single object and it really makes sense to operate on a whole row at a time. There are other similar issues here, for example, obscure keyboard navigation behaviors are a little different. The point here is that the abstracted component, in the end, doesn't do "spreadsheet" like interfaces perfectly nor does it do list-like interfaces easily, even though both ultimately display a 2dimensional grid of values, because there is too much in the way of "grand unification" here. (in consideration of the Swing team, I'm sure the JTable component was created before the different roles it might play in an interface were discovered).

So, how do you determine the right level of abstraction? (after all, you probably don't want a one word processor for 5 page booklets and another for 15 page booklets!) As always, this goes back to the issue of looking at the needs of your users and determining how your software will be used by them. Are the things you are trying to unify genuinely unified from the user standpoint (probably so in the case of GRUB, for example. Probably not in the case of JTable)?

Presenting the conclusions first often makes a document more interesting to read and actually helps orient the reader, though it may take more effort to create.

I was working with a friend, recently, who was writing an essay for a graduate school application. The structure of his essay was basically: "Point1, point2, point3, point4, thus conclusion". The content was all good, but it felt heavy and uninteresting.

I suggested that he change the structure. Something more like: "Conclusion, because point1, point2, point3, point4". When he did this, not only was his essay much more engaging, but it was very easy to see how his points fit into a larger picture.

Today, I was reviewing more of our documentation, and realized it is doing the same thing as my friend's initial draft of his essay, but on a much larger scale (tens of pages, rather than tens of lines). In order to understand how to do a particular task, the documentation takes you through the whole infrastructure and concludes with the actual steps of the process. The result is very difficult to read, because as you must remember everything without knowing why you are remembering it. Only when you are done do you know how each fact is supposed to fit together. So the effort to read it is very large. Not very usable.

This does beg the question: Why do we end up writing documents (including blog entries!) in this unusable way? I think one reason is because it is the easiest thing to do. If I have a conclusion to make, it is much easier to think through (and write) the support for it one step at a time. Then when I reach the conclusion I'm sure I've made my arguments to support it. Another reason may be that there may be some psychological benefit (to the writer) of delaying telling the reader the answer until the end. You get to do the "I'm the expert, let me keep you guessing until I've revealed my brilliance." thing. And some may be simply the (misguided) notion that my reader needs to understand the details before they can understand the conclusion.

In any case, this is another example of how making something usable is not necessarily "obvious" from the point of view of the person doing the creation. It may even involve more work (doing a full first draft that ends with a conclusion, and then a full second draft that starts with the conclusion). However, the results can be substantially different.

In the past couple weeks I've spent some time in some of the local hospitals (I'm fine. Don't worry!). Again and again I found myself marveling at the poor first-time user experience of these places.

For example, I had to go to one place at Stanford Hospital. There are signs on the road that say "Stanford Hospital". But, when you get there... well, it isn't entirely clear where "there" is. If you look at a map before you go, you might have a chance of finding your destination. Or not. If you don't, then as you drive in, you have no idea where "the hospital" is. The road layout implies one building is the main location, but I don't think it is (it's called "Stanford Clinic-Boswell", not "Stanford Hospital"). By the time you've gotten "there", of course, you've missed all the parking. So you must go back and find parking (If you are with a patient, and all the visible signs say "visitor parking", should you go somewhere else to find "patient parking"?). From there you must wander around and ask people where to go. Someone tells you to go to "Radiation", but as you walk down the halls you only see signs for "Radiology", and as far as you know you're there for a CT scan (which if you are technically inclined you'll know involves radiation, but otherwise it must be frightening to be seeking out "radiation" which you know isn't healthy).

If this were a software product, we'd say the "out of the box experience" here was not very good. If someone ends up in part of the software and don't know where they are, we'd rate that as bad. The need to consult documentation (ask directions) is probably a failure of software usability. Labels proclaiming dangerous things ("Terminate!", or in this case "Radiation") are generally discouraged, and signs that reflect underlying implementation details (radiation when the user wants "CT") are marks of poor awareness of the user.

As I went through this experience, it was clear to me that this hospital had not done any prototypes, usability studies, or similear research to test out the experience of a first time visitor (or they'd done this and not acted on the findings). Nor did they evaluate the materials they gave people. Consider the map I linked to above: the heading is "SUMC SITE MAP" (what's SUMC?) and one of the parking structures is "SHC Patient Parking" (what is SHC? does it correspond to one of the buildings, like the LPCH Patient Parking presumably does? If so, which building?). Why is it telling people where employee parking is?

In the field of software, we tend to believe that these little details make a difference to the adoption of our products. A hospital doesn't necessarily have the same competitive forces we do (that is, few people probably say "Oh, I find it easier to find my way around Foo Hospital, than Bar Hospital, so I'll go there instead"). However, we also believe that a pleasant user experience in the software makes a happy user, and Don Norman points out that a pleasant experience allows people to solve any problems that they do encounter more effectively. This is certainly applicable to hospitals as well as software. Indeed, given that most people visiting a hospital are probably not in a happy state to start with, this is all probably even more important.

(I could go on to talk about the harsh beeps and other noises that made by some of the medical equipment (what were the designers thinking?) But, that's another topic...)

I'd like to start today's entry by following up on the last one. Alex McKale kindly commented that he'd heard of the point about people commenting on minor details and ignoring large ones as "building a shed". This week, coincidentally, I found this URL in an email message in my inbox which discusses the same idea and seems to mention where this idea of "building a shed" comes from. Good to know.

Today I spent some time looking at the documentation for one of our products. It isn't bad. There's actually a lot of great documentation there. At the same time, this documentation seemed to reflect an old-style engineering approach to documentation. Sit down, document your technology comprehensively from start to end. This is useful at times, and even needed.

Yet, again and again in usability studies, what we see is that most people try to use software based on previous experience, and then turn to documentation only when they run into problems.

This is a difficult situation. On the one hand, some people probably do need to read the documentation thoroughly to understand the system. And it is probably crucial to serve those users since they probably (and I'm speculating here) serve as information resources for large networks of people that don't read docs. At the same time, there's a tendency in most software products to primarily deliver "comprehensive" documentation. Sometimes there's a push to deliver "task-based help". Yet, for the average user this doesn't really help much. Again and again I've seen users in usability studies say, effectively, "Oh, the help/docs is never very helpful, so I never look there."

Documentation (taken broadly) in the end is an important part of the user experience. People do run into problems and need to consult information resources. The problems here is that, ironically, the better your user model is, the easier it is to write docs, yet the less they are probably needed.