David Burrowes' Blog

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.

Here it is, three days before the Christmas holiday. Sun, in the United States, shuts down from December 25th to January 1st each year. So, I'll have no posting here next week. Instead, I'll be spending some time away from computers for a while!

I was part of a discussion about command line interfaces this week, where the issue of optional option-arguments was being discussed. For example:

$ myutility --foo  thingie

$ myutility --foo=value thingie

The discussion went on for great length with the folks discussing (among other things) whether this was a different kind of interface detail than one other.

This got me thinking about small interface details. I remember one email discussion, a few years ago, which went on for days about the use of ellipses ("...") at the end of menu items. How and when they should be used. I've seen long debates about whether icon X or icon Y should be used.

While I was part of the NetBeans project, I remember times where someone would suggest a tiny interface change and there would be a storm of discussion about this on nb-ui. At other times, a design for a big change to the interface would be suggested and there would be almost no comments raised.

Why is this? Why is it that tiny details raise such intense discussions while larger issues often don't? Here are some thoughts:

* The people challenging the idea are actually seeking some level of ownership over it. When they are focusing on the particular detail, they aren't actually interested in that detail but instead are seeking to try to use this detail to persuade themselves to adopt the ideal.

* Those challenging the idea may actually be trying to test out the presenter. They've picked this more as a way to verify that the presenter knows what he or she is talking about, and again are less interested in the detail itself.

* Both sides hope that by convincing the other about this small detail, the other's whole framework will collapse. So, the discussion around the detail is actually hoped to be a vulnerable and critical point in the whole system.

Perhaps there are others, too. In all those cases, the detail is being used as a proxy for discussion about something larger.

In many cases, though, I think the reality is that it is simply easier to think about and criticize a small thing than a big thing. This is actually dangerous both for user experience practioners and for those challenging them. As a UI person, I've more than once delved into offering "constructive feedback" on the details of some design and neglected the larger issues (e.g. worrying about the naming of some menu item and neglecting that the menu item would probably never be used because of some systemic usability problem). And I've certainly been on the receiving side of that as well.

The funny thing is that good UI design often requires one to look at as large a picture as possible. The usability problems there can easily dwarf any and every small (and easy to identify) usability problem. By the same token, successful design in the big picture can render small usability problems basically irrelevant (because, really, people can usually overcome small problems relatively easily).

The message here is that when doing UI design, one should often strive to let go of the small details and concern oneself with the big user experience issues. Don't worry about the positioning of buttons first (an easy thing to identify). Instead, make sure the tasks that someone would want to do can be done with the app (a hard thing to identify).

A colleague sent me this link to an article on Slashdot today:

Conducting a Unix Desktop Usability Study?

In short, someone is going to do a usability study comparing initial experiences of KDE and GNOME.

A few of the comments by the community were things like this:

Who cares if the first time someone uses the environment that it takes a little orientation to get used to? In the real world, if a couple of weeks of pain makes you much more productive after that, it's a net benefit imho - the remainder of your time using the environment outweighs the significance of the learning time.

A few years ago, my manager here started making a big push on evaluating "out of the box experience" issues. That is, first time use of a product. At the time, I thought this was a little misguided to put so much emphasis into this small sliver of the user experience.

Yet, over time, I've come to see that if you get this portion of the user experience wrong, nothing else matters.

Twenty years ago, all software was relatively hard to use, and so everyone expected to have to put in some "pain" to get going.

But, technology has become omnipresent, and step by step folks have made getting started easier (not just easier, but increasingly "delightful"), more folks (without time and interest to tinker) have become tech users, and even tech experts have substantially more tech stuff to learn and use than they used to. (in 1984, the whole MacOS, plus bundled apps fit on one 400K floppy). If your stuff isn't easy to be productive with instantaneously and it isn't absolutely critical to someone's life, that person will abandon it quickly.

It is true that for a heavily used system, over time you do become more productive as you learn your way around the system, and those aspects should be worked on too. First time use is absolutely not the same as experienced use. Yet, the only way to become experienced is to use it for a while, and the only way there is to get the initial experience right.

I've missed two weeks of entries here. I was on vacation for the US Thanksgiving holiday and then last week at a conference.

For Thanksgiving, I took a train (Amtrak) from California to Oregon. A nice, relaxing trip. I was surprised at how bad some of the guidance was.

Both in California and in Oregon, when the train arrived, there was no indication of which train car you were supposed to go up to. In contrast, when I was recently in China, my ticket clearly told me which car to go to, and when the train stopped the conductors came out and put numbers up by each door. Here, the rule seems to be that you just pick a car at random, hope it is the right kind (sleeper or coach) and they'll assign you to a seat then. I'm sure this is not a big deal once you are familiar with the system, but it was baffling to a first-timer.

Then, on the train, they'd (usually) call out the name of a city when the train stopped so you would know if you should get off. But, unless you knew all the stops, there was no easy way to tell whether this was the stop before your destination or far from it.

Both of these are more or less "first time use" user experience problems. These are the kind of problems that you can overcome without a lot of problem (you just ask an official-looking person). Yet, they could also be solved quite easily (a note printed on the ticket and a map near the entrance of each car would be minimally sufficient).

I found myself wondering why Amtrak didn't have solutions to these problems. While not critical problems, they are certainly dissatisfiers for more than just me and make the organization (Amtrak) seem a little unprofessional.

Yet, this is of course the same kind of problem many software products have. Presumably people within the Amtrak organization know how things work well enough that they don't stop to think what a newbie needs to know. They don't consider that a newbie hasn't memorized all the stops on each line. Similarly, software products often assume you already know the entire user model/app architecture or where all the commands are.

Like many software products, Amtrak probably doesn't recognize that first impressions really do count for a lot. If you spend your whole first trip on the train wondering "I wonder if I'm going to miss my stop" (I saw people occasionally who did indeed miss their stop) you end up building a negative emotional reaction to the experience which lingers even if you successfully conclude the experience. The same, no doubt, happens with software.

(fwiw, I did enjoy my train trip, and I'll probably do something like that again. I am not, however, left with a lot of trust in the Amtrak organization).

One day when I have time, I'd like to create a prettier (or, at least more personal) look for this blog. In the mean time, I've switched this to a different one of our standard templates. I found the dark brushed-metal one rather oppressive.

I thought I'd comment today on something closely related to the one I wrote last week.

Recently, I was talking with a project group about what they were doing. During the conversation, it became clear to me that they were doing something rather UI intensive, and they should have a user experience designer involved. When I suggested this, they answered "when we're further along, we'll think about it. We see UI as refinement."

Now, I was a little offended by this. As I reflected in my previous blog entry, architectural designs affect the UI, so regardless of how this reflected on me, it was also just wrong.

But, why is it "wrong"? I thought about it more and found this way of thinking about it:

The user experience is always being designed from at least the moment the first line of code is written, even if there is no usability designer involved at that point. So, when these folks said "We see UI as refinement", what they really said was "We like to do most of the UI design and then ask someone else to finish off the work that is either too boring or too far outside of our expertise." I can understand this, of course. We all like to hold on to the most creative control over the things we create. As a UI designer I've been known to try to hold on to more of the design process than I probably should have.

So, really, you have only two choices: you can explicitly do user experience design from the beginning of your development process, or you can do this implicitly and as a byproduct of other decisions. The implicit process, of course, has a much higher chance of delivering a product which users won't like using. If they don't like using it, they either won't, or your competitors will allow them to do the same thing in an easier way.

Here is an interesting article:

Will Short Scope Hinder Slashdot Redesign?

In this article, the author, Khoi Vinh, mentions that Slashdot is seeking a redesign of their web site. Yet, this redesign is confined to changing the look of the site, not changing the underlying architecture of the information on the site.

To my mind, this reflects a common view of user interface design. Many feel that UI design is about making some existing thing prettier. Rearranging buttons in dialogs, changing colors, adding better icons. Often, though, this is the same as putting lipstick on a pig. (which is not to say Slashdot is a pig. Just that other software projects have a certain swine-like forms).

Good UI design starts far beneath the surface. It has nothing to do with look, and little to do with feel, and almost everything to do with arranging the underling information and entities in a way that will be sensible to the user. With the right underlying structure, a good interaction model can be put on top, and then a good "look and feel" can be added on top of that. Without this, the underlying model will become aparent at all the levels above it and the resulting user experience will be problematic.

The hard part is that that underlying model is usually in the same "place" as the system architecture. And this is non-intuitive to those that see UI as just "look and feel". They don't expect that their "engineering architecture" will affect the usability.

Let's consider one example. Application delivery architecture. On Windows and Solaris, an application often consists of multiple files. A primary executable, maybe some help files, maybe some documentation, maybe an uninstaller. On the Macintosh, and application is a directory, containing all those same things. An interesting byproduct of this architecture is that it is very easy to install a very complex application on the Mac. The environment treats these "application directories" as a single "file" to the user. So, to install one of these apps just involves a drag and drop operation. Indeed, I seem to recall that "installing" the whole Microsoft Office just required me to drag one thing from the disc to my Applications folder. In contrast, almost any interesting application on Windows requires an installer to place all the files in the right place (not to mention updating the Registry and who knows what else). The inverse operation, removing an application, is generally easy on the Mac: drag the application (folder) to the trash. On windows, it requires an uninstaller.

It is interesting that the Mac application architecture is, in this spirit, the same as the NeXT application architecture, so this is an old thing. Was it created to facilitate application management like this? I'd certainly like to think that someone said "wouldn't it be great if users could install all the complex parts of an app without an installer?" and then that birthed this application architecture, rather than the more common model of creating an architecture and wrapping the user experience around that.

It occurred to me today that I haven't heard the word "killer app" used in a while. I think that's interesting, because I used to hear it all the time. It tended to mean (as the wikipedia will tell you) an application which was so compelling that it would cause someone to buy all the necessary infrastructure to run it.

Though the term seems to have vanished from my side of the world, some of what that term alluded to remains quite important. I remember talking to one developer in Beijing, and asking why he used Windows rather than some version of Linux. His answer was that one big reason is that there was a special IM client he used with friends that only ran on Windows. I do some volunteering to maintain the technology infrastructure at a nearby charity, and they're all Windows-based. I would like to have been able to recommend that they use something else. In theory this might have been doable for many of them. However, many of them also were quite invested in a database application built on top of Lotus Approach. Switching to another OS would have meant finding some way to get that ported.

These examples aren't quite "killer app" examples, as that term always seemed to mean a novel and exciting application, and in these cases, these aren't novel apps. They're pretty mundane, actually. But, they are useful or necessary apps for these people, and when all other things are equal, it is these critical apps which decide the OS.

I'll tie all this back to usability by pointing out that it is rarely a particular feature which creates a critical app. Nor is it usually a particular bit of "ease of use". Usually, it is some critical need which the software either solves or creates and solves which compells a person to decide the rest of their computing environment. When doing user research for your product, it is certainly worthwhile to determine what the critical needs that your customers have, and how that will influence their adoption of your software.

I get to do some command line interface design work here at Sun. This sometimes is surprisingly valuable. The overal range of issues around command line interface design is much smaller than in graphical design. You don't need to worry about spacing or colors, dialogs or windows, asynchronous messages or dynamic layout. The "skeletal" nature of the design work makes the issues between architecture design and interface design much more visible. This, in turn, gives me a much clearer window into the classic programmer/interface-design differences. This fascinates me because it is often the vast differences between these two necessary disciplines that produces difficult-to-use software.

(I also won't deny that one of the fun things about doing design work in the command line arena is that there seems to be very little knowledge about this topic in the UI field, which makes every usability study I do a rich source of new insight into how people use software).

Anyway.

Recently I had my programmer's hat on. Which is to say I was coding. I was actually writing a small command line utility that I was going to hook into a set of scripts I have for doing web page creation.

I wrote this:

int main(int argc, char** argv) {

  int result = 0;



  if (argc < 2) {

    printf("%0: Usage: %0 file1 file2\n", argv[0], argv[0]);

  } else {

Let's ignore that I should have been using getopt() or getopt_clip() or getopt_long() here. This utility will never be used by anyone but me(tm), so it's OK(tm).

I couldn't help but look at that printf() statement and wonder about the usability monster I'd just created. Personally, I really don't like these utilities that, when you give them some kind of bad syntax, report back some very terse usage message.

$ gstlcfg -a suger

gstlcfg: Usage [-abcdefgh] type

If you are familiar with the utility, these usage messages are great, because usually you just did something foolish and the message will remind you in a way that will allow you to quickly fix the problem.

If you aren't familir with the utility, however, the message can be useless. Or, worse, it can make you feel insecure about the utility and even the whole command line environment. Bad user experience.

So, giving a better message there might be good:

    printf("%0: You must pass two file names to this utility, but you appear to have inclued less than two.\n", argv[0]);

I suppose that's more useful (but, we've just lost the benefit of terseness to the frequent user of the utility). But, there's another problem here. There are other error conditions that can happen later in the utility. For instance, I might have included two names, one of which doesn't refer to any file. Later on in the code I'd discover that, and probably report a different error message (e.g. "The file (%s) does not exist.").

Now, if you look at these messages from the end user's standpoint, you'll realize you'll get two very different messages for what are almost the same error condition to the user. It isn't that the two messages couldn't be almost the same, it is that when coding I'd lost sight of the fact that these two points in the code, which were many lines apart and created far apart in time, were close together to the user:

$ myutility foo

myutility: Usage: file1 file2

$ myutility foo bar

myutility: The file (bar) does not exist.

As a developer, of course, I understand that the latter message is different because it is happening at a different time in the parsing process. But, not all CLI users are developers. This is just "randomly" different messages.

The point is that while I was typing in the code here, I "discovered" the first error condition and I wanted to deal with it as quickly as possible and get on with writing additional logic in my utility. So, I dealt with it in the best way I could at that moment. While I was concerned about the user's needs, I wasn't concerned enough to step back and say "What is the overall set of experiences the user will have at this point in using the utility? And what's the best way of reporting the message". Indeed, my message was actually pretty self-focused. I wanted two filenames, and I didn't get them so I was complaining "you didn't give me to filenames".

Having satisfied myself that I was letting the user know something so they could correct the problem, I turned my attention back to adding more logic. When I found the second error condition, I did much the same thing ("Yo! I need a REAL filename here"). These conditions were far apart in my code, and because my attention was strongly focused on the point I was in the code I didn't really realize that this was the same to the user as the condition I'd dealt with earlier.

So, the next question is: how could I have prevented this small problem. How could I have made sure that as a developer I would have generated better error messages for the end user without disrupting my goal of creating functionality?

Part of the answer to that would be to have had an interface design in my hand before I started. That way, when I found the error condition I could look up in the spec "Oh, I'm supposed to give this message". Lacking a spec, I could have relied on some general guidelines (e.g. "Check all command line arguments before starting actual processing, and when there is an error report the message in this format." In both cases I could have then reported "the right" thing and gotten on with my work well.

At the heart of this issue, the fact of the matter is that identifying all the error conditions, and how they will appear to the user as the user uses the utility is actually a non-simple task. It requires looking at the software as a whole, while ignoring how it will be implemented. Good design would mean considering the needs of the various classes of users and making sure the information presented meets all of their needs adequately. In this case, doing that well would take almost as long as it took to write the code for the utility. As a developer, in the flow of coding, I am simply not going to step away from my work long enough to do all that analysis. It ruins the flow and (as I've pointed out earlier in the blog) takes a substantially different mindset to accomplish.

As a result, it is natural (even necessary) to downplay the importance of the interface issues to focus on getting the logic created. And, from this we get software that is difficult to use.

I guess the moral here is that interface design should be done not while coding, but separately. That way, each task can take advantage of the different mental skills involved in each, and neither disrupts the others flow. Of course, when you are dying to start coding the design work seems like a burden and nuisance. And when you are dying to do the design, the coding seems like it's leaping before looking.

A friend pointed out that it would be good for me to introduce myself on this blog. I think that is a good idea.

My name is David John Burrowes. Friends call me David.

I have worked in the software industry, largely in the US Silicon Valley, for the last 15 years. For the first 9 years, I worked as a programmer at a variety of companies. I wrote database drivers, data access applications, in-house "mission critical custom applications" (remember that term?), productivity apps and probably some other stuff I can't remember just now. I've written in Pascal, Visual Basic, C, C++, Objective-C, Postscript, Java, on a wide variety of computer platforms.

Several years ago, I transitioned into user interface design, partly because the programming problems were seeming increasingly dull (Wow! Another way to retrieve a row of data from a database! How exciting! Zzzzzzzz), and partially out of an increassing interest in the topic of interface design. (I have a degree in Cognitive Science, so this transition was less extreme than it might seem).

Since that transition time, I have done interface design on productivity applications, system management tools, programming languages, web applications, development tools, command line utilities, and other things. One of the blessings of working at a big company like Sun is that there are a wide variety of things to get experience with.

I've started writing this blog partially to share some of my thoughts about Sun and interface design, as well as a place for me to try to articulate some of the issues involved in the work. It seems increasingly aparent that interface design (or, really, experience design) is going to be more and more important in the future of software, and I'm really interested in finding ways to get this design work better integrated into software products.

In my spare time, outside of work, you'll find me ballroom dancing, learning Mandarin, doing some volunteer work (which has surprising work-related ramifications, since I see completely ordinary people trying to use computers every week), as well as hanging out with friends.

I ran into a design situation recently which exemplifies a common problem with software design and usability. In actual fact, I'm exagerating some of the details and the overall design has gone in a different direction. Still, I thought this point was worth extracting and simplifying in order to make a general point.

We had a command line utility (yes, command line utilities have interfaces (the "I" in CLI is interface) that can benefit from HCI design) which did some general purpose work. Let's say it could set some properties on something. It was something like this:

myutility set \-p myproperty=myvalue \-p myprop=myval ...

One of the properties actually didn't work very well with this interface scheme. Let's say if you specified the property it would have to ask for confirmation because it was a very destructive thing to change. One reaction to this was to say "well, this whole interface is no good. We should do something completely different."

This often happens with software. There's some special situation which doesn't fit the general rule very well, and this forces an overall change in the interface design. Sometimes this makes the interface more complex Perhaps in this case it would have resulted in a separate utility for each property setting, so that the special property could be handled in a more predictable way. Maybe something like:

setmyproperty myvalue

setmyprop myval

...

In this case, having the utility come back with "Are you sure you want to do that" would not be such a big deal (like "rm \-i"). Also, these utilities are now very consistent with one another. But, perhaps you can also see the loss involved in this interface. Where before there was one utility to learn and remember, with one man page which is pretty easy to scan through and one \--help output, now you have a bunch of utilities, either many man pages or one clustered one, and non-shared \--help output. It is probably less easy to use.

This relates back to my post a couple weeks ago about differences in design heuristics. For a coder, this is a clear win. The architecture is very consistent and the rules are easy to state. It must be easier to use!

Yet, most users never come close to understanding the architecture of the software they use. It is too complex and they don't spend a lot of time using any individual piece of software. So what is an improvement for the developer is invisible to the user. And, in this example case, the usability of the interface has gotten worse.

Another alternative might be:

myutility set-destructive-property newvalue

myutility set \-p myproperty=myvalue -p myprop=myval ...

This is not a beautiful bit of architecture. It makes the developer in me unhappy. But, it is probably a better user experience (one man page, one bit of --help output, one utility to remember), and people are remarkably able to deal with special cases if in some way it makes sense in their flow of using the computer.

So, my general point is: Be careful of making big changes to your interface to accommodate small special cases. Often those big changes create a less usable interface than creating a generally easy to use interface with a special case interface in it.

Another entry from Slashdot (see the article on Slashdot). It seems that BetterDesktop (Novell/OpenSUSE) have contributed many videos of usability studies of open source projects to the community. There is also some raw information and some reports available.

I think it is great to see this kind of information being gathered and made available for open source projects. Certainly, I'd like to see more of this kind of thing.

It would also be nice to get a little more demographic data about the participants in the study, such as what they do on a daily basis. (I used to say "subjects", but had a co-worker point out that the people aren't actually the subjects of the study. It is the software that is the subject. As we sometimes say "We are testing the software, not you". So now I call them "participants". What do other people call these folks?)

There is often a lot of tension between User Interface (UI) Designers and Coders when it comes to deciding who "owns" which parts of a piece of software. It is relatively well known that there is some genuine overlap. Changes in UI can force change in deep architecture, and change in deep architecture can change the UI. Most folks realize that a good UI is not just something layered on top of an existing architecture.

Yet, even when you take that into consideration, and the people involved understand this, there are still sometimes significant conflicts between these groups. One group knows that the software must be like X, and another group knows just as certainly that the software must be like Y. Neither group makes much sense to the other. As a result, you get coders grumbling about the clueless UI people and UI people grumbling about the stubborn coders. (it isn't always like this, of course)

Sometimes I wonder why we need the two groups. Why not (say) get rid of the interface designers and just ask the coders to do all the work. On occasion, I've actually seen this done successfully. In general, of course, it doesn't work well. What is particularly funny for me is that I've spent many years as a coder and then as an interface designer. I think I do both jobs pretty well. Yet, when I put my coder hat on full-time, I tend to produce pretty poor user interfaces (which is embarassing). I've asked myself why that is. Which leads to this long blog entry.

After some reflection, I've come to realize that the design rules (if you will, their design heuristics) that coders and interface designers use are almost complete opposites. I believe that this underlies some of the reason it is sometimes so hard for one group to communicate effectively to the other. To make this concrete, a good progammer pays great homage to these rules:

* Make things modular
* Create general-purpose things
* Expose all potential functionality

In contrast, a good interface design involves these rules:

* Make things non-modular
* Make things as special-purpose as possible
* Hide non-crucial functionality

Let's look a these in more detail.

MODULARITY

Programming is immensely complicated work. Every line of code is essentially a tiny machine. So, a tiny program of 1000 lines is made up of 1000 machines. Can you imagine trying to build a physical device made up of a hundred thousand pieces? Does that make your stomach roll up into knots? Ever tried to reassemble a device with maybe 10 screws and found you somehow ended up with one extra screw? Now imagine a machine with five thousand screws. Yeah. Programming is very hard. One way of dealing with the difficulty is to put those lines of codes into very distinct clumps, and arrange these clumps so they do not interact with the insides of other clumps. This reduces the range of possible complications that can occur, and so reduces the chances of bugs occurring. This is called modularity. It keeps a programmer sane.

In contrast, a good user interface is not at all modular. If a term is changed in one dialog accessed from the file menu, then it must be changed throughout the application. More than that, changing that term may require icons elsewhere get changed, and sometimes can even involve adding or removing components in a dialog. For example, if the decision is made that the wad of data should be called a "zFile" rather than a "zRecord", then this might dictate that something resembling a file chooser should be used in some parts of the interface rather than a tabular list of records. Changes to the layout of components in one dialog might demand that other layout changes are made to all dialogs so that an overall consistency of experience is maintained. A good, quality interface expresses itself in the same way visually, terminologically, behaviorially, and even attitudinally throughout at least one application (and preferably throughout a whole suite of applications). Interface design is inherently and necessarily not modular (not for the sake of the designer's sanity, but for the sake of the end user's, since users expect things in their environment to be consistent).

Already, perhaps you can begin to see why interfaces created by coders are sometimes difficult to use. When confronted with a problem, a coder will tend to rely on the design rules they have spent years learning: make it modular. In fact, this is the design which makes the most sense to a person wearing that hat. It just isn't the design which makes sense to someone not steeped in that tradition of thought.

GENERAL PURPOSE THINGS

Related to the modularity issue is that of reusability. Coders are trained to write modules of code that can be reused. This is a significant way of saving time and effort. If you can create something once and reuse it repeatedly, that will obviously save you time compared with creating the same thing over and over again. The oportunities for creating general purpose modules is vast in programming. For example, operating systems can be thought of as vast collections of general purpose modules of code that are used by many coders. Within individual applications, there are often modules that are used heavily by different parts of the application. Because coding involves creating so much stuff, coders are always looking for ways to solve a problem in a general purpose way so that they do not need to solve it again later. When they're not creating general purpose things, they often are modifying existing things to make them more general purpose. Thus, a coder learns to do general purpose creation instinctively, and may add features to a module that won't be used at this moment because she knows those features will eventually be used by other parts of the program.

In contrast, good interface design often seeks to specialize. In theory, you could use a single piece of metal as a ruler, a nail file, a knife, a screwdriver, a pry-bar, and a putty-spreader, and many other things. But most of the time, we buy separate rulers, nail files, etc. Why? Because for practical reasons it is better to have a set of specialized devices than one universal one. We can put them each in different places, each can be fully optimized for its use, and so on. You might say that a tool is easier to use the more specialized it is, and the constraining factor here is how easily we can find and remember how to use the range of devices.

Again, notice that the coder and the interface designer approach their problem spaces with opposing attitudes. Also note that the coder's goal of modularity and generality reinforce each other, while the interface designer's goals of non-modularity and specialization mildly oppose each other. Interesting, eh?

EXPOSE ALL FUNCTIONALITY

Once you have created something that is modular and general purpose, you want to make sure that someone will be able to use it in any situation, including those that you haven't thought of. This means that you need to figure out every possible bit of functionality provided by your code (including those uses that might happen once every thousand cases), and then you must expose it so other modules can possibly use it. To do otherwise would compromise both its modularity and its general purpose use. Any coder has run into cases where some library they are using doesn't provide access to one bit of data or one "obvious" bit of functionality, and they must then devote large amounts of energy to providing some way of getting around that limitation. This is often painful and very frustrating (what would have taken the original developer maybe 5 minutes to do now takes half a day for the coder using that library). This pain teaches coder expose the full logical interface to your module.

Interface designers, on the other hand, know that people hate making choices. And when presented with (say) more than one thing, they slow down and have to make a choice. Thus, the best interface is the one that has the fewest choices. When there are genuinely a lot of things that someone can do, the designer learns to distribute the functionality in ways so the most frequently used functionality is most obvious. Other functionality may be buried (e.g. you have to open three dialog boxes to get at it), and there are other strategies to use as well. In some cases, some functionaity is just never presented, because it doesn't justify the pain it would cause users to decide whether to use it or not. A serious car enthusiast will tell you that you can increase the performance of your car by some percent if you go and adjust some things in the engine and then you will just need to monitor the adjustments more often. Many drivers, however, simply don't care about that. They would rather have a car which performs a little less well, and accept the fact that they can't adjust every detail. It is the same with users of software. Most people do not want to adjust their software. They don't even want to open a simple Preferences window if they can avoid it, much less be asked to choose between five different ways of rotating a graphic. Obviously, how much functionality someone needs depends on the user type and the task type. But it is usually the case that the end user does not want or need as much functionality exposed in their interfaces as it is possible provide. So, an interface designer deliberately hides or removes potential functionality in the name of making the software tolerable to use.

There are other differences between the disciplines, as well. A social psychologist will be able to point out different ways the members of these groups prove their value to each other, for example. I'm not going to go down route.

Instead, I'll just summarize by saying that practicing good UI design involves design rules that are completely in opposition to the design rules that a good coder must use. Each person can better understand the other's viewpoint in a given design discussion if they remember this, for it will help explain why the other person seems to be making "insane" design suggestions. Neither set of rules is inherently right or wrong, for each is necessary to the creation of quality software.

Slashdot had a posting today about a proposed/possible US$100 laptop designed by some folks at MIT.

I think this is interesting, and the device itself looks kinda cool. I wouldn't mind having one of those as my laptop (OK, I'd want the model with a faster processor... )

But, of course, this is interesting to me not just as an individual, but also as a Sun employee. We have recently rearticulated some of our values and goals, given the current state of the world. We've decided we want close the "digital divide" (Search results on the web demonstrate that we're at least generating some buzz with this). One can see some business sense in this. I also think this concern for the "have nots" is something one finds throughout in the hacker/geek culture, and so it isn't at all odd for Sun to place this so prominently in its corporate identity.

A US$100 certainly would make laptops more accessible by those that need them. My only question (and you certainly must have seen this coming) is: When will this laptop be running OpenSolaris, rather than Linux?