David Burrowes' Blog

Hello dear reader.

I'm going to be taking a leave of absence from Sun soon so I can study Chinese full time (I'm very grateful to have this opportunity). So, this is likely to be my last entry in this blog for a while. Indeed, the preparations for my trip are why this week's entry are as late as it is.

One thing I've been doing is setting up an account on gmail (free pop access to email seems useful). I've not really used gmail much before, and noted something interesting about it today.

The layout here looks like an ordinary email program. Each row seems to be a message, with columns for sender, subject and date.

The interesting thing is that this isn't really quite what is being presented. Each row is actually a (hopefully related) group of messages in one conversation created by a set of people. The "From" column lists the people who have contributed to the conversation in the order they've responded (bold indicates you haven't read that entry, and a double dot indicates when there are more entries than can be shown in the column width)

There's nothing inherently wrong with this. While it may be a little unexpected at first ("What does it mean for a bunch of people to have sent a message?"), it is close enough to the "traditional" model that it is not hard to learn what is going on.

As I looked at this, though, I found myself wondering if there might be a more fruitful way of displaying this information. The "From" column (really, the "active participants" column) is trying to show a lot of information in a really small space. My first thought here was that if you could associate a picture with each person, then you could actually get a longer list of people in the conversations here. Rather than two or three names in the column width, you could get ten or more.

In theory, this seems like an improvement. In practice, I'm not sure the pictures would be large enough to let you identify the people:

Yet, when I look at this, I still can't help but feel like something is wrong with this design. Each row is a whole conversation, not an individual message. The prominence of the people involved is interesting and unexpected. It would seem to me that the system could quickly begin to notice that a particular set of N people are routinely involved in conversations with one another. Perhaps it could begin to deduce some social clustering. At that point, it might be more fruitful for the software to present messages in terms of the social groups first, and the individual conversations setcond. that way, one could effortlesly look at all the conversations with one's project group at work, first (and ignore messages from outside the group). Maybe this would look something like this:

Or, perhaps it would be better to show which group members participated in each thread:

Or you could imagine many other possible designs for something that is social-group oriented as much as it is thread-oriented.

Of course, at this point in time, email serves many purposes for people. It is a to-do-list, a paper trail, a file exchange medium, a reminder mechanism, a communication channel, and so on. something like this wouldn't fit all the uses of email well. So, maybe that means this is a bad idea. Or perhaps the fact that those usages don't fit into this design well actually suggests more design innovation that could be done.

If I have a central point to this entry, it might be that sometimes when your interface design seems a little strange, it may actually reflect an opportunity to do something novel. (and I suppose a variation on that idea would be : if a design is bad, it might be good not to dismiss it as a bad design, but investigate whether it suggests other possibilities that you hadn't considered before.

Last week I noted that I'd been looking at the networking user interfaces for WindowsXP and MacOS. I've been building inventories of thse on the OpenSolaris web site off this page Networking "state of the art"

I am intrigued at how different these two interfaces are, even though the deep system architecture is about the same: There is a software representation of each path one can use to access a network ("links" in unix talk). The operating system keeps a group of settings which it applies to the links, one link+settings is active at any time and when applications seek to use a network, they use that active entity.

On Windows, you have a "Network Connections" "folder", which contains an icon representing each physical or virtual/software access point ("link") to a network:

You can get a contextual menu for any one of these:

and perform operations on the connection, or just access its properties:

There are also stand-ins, of sorts, for the network connections that can be shown in the system tray:

and you can perform similar operations on those.

This seems quite logical. In fact, it is very "object oriented", which at least used to be viewed as a great way to model the information in a user interface.

This is clearly usable enough that millions of people manage to get their Windows systems talking to some network.

At the same time, there are some drawbacks to this design. Most folks I talked to about this aren't entirely clear what the icons are in the "Network Connections" folder. They know they are networking related. When there is a network problem, they know the properties of those objects must be manipulated. But, that is about the extent of it.

This direct projection of the system architecture into the user's space, then, doesn't add much value.

One aspect of the "object oriented" approach is that all the manipulation of the objects is done through property windows. If you look at the images on this page, you'll see that almost all of the snapshots are of the main Properties window or windows opened from within the Properties window. There are an enormous number of settings available here, if you are willing to dig down through the interface far enough. Some of the settings bring up windows for other objects related to this network connection.

Certainly, the strength of this approach is that you can probably configure almost everything about the network connection through the graphical interface. If you want to change something obscure, documentation can tell you where the setting is, and as you drill down to find the setting the information in proximity will help explain to you what you are setting.

The downside is that if you aren't familiar with this information architecture or don't want to learn it, this is just a baffling set of random windows and scary looking settings.

Perhaps I'd describe the overall theme here as: system management through manipulation of properties on "objects" (not in the programming sense) in the operating system.

The MacOS X interface for configuring the network interface is radically different. Of course, like Windows, at some level there are "links" and there are settings applied to those links. But, this are in no way prominently positioned in the interface.

Notice that on Windows there are (from a user vantage point) no applications involved in configuring the network. On the Macintosh, there are several. The network configuration is done through the System Preferences application. Another application, Internet Connect is used to control the connection and disconnection of things like modems. There are also a set of little menus which allow you to control individual network behavior.

When you dig into the System Preferences application, you do eventually find the links. They show up in the menu shown here:

Ultimately, choosing one of those lets you specify the settings for that link.

The names of the links are the same names used elsewhere in documentation to refer to the physical ports the user works with on the system (e.g. "Built-in Ethernet") rather than the Windows style of describing the role of the object ("Local Area Connection").

Unlike Windows, I don't think the Mac makes any serious attempt to explain the system architecture to the user. In fact, that architecture is three levels deep in the user experience (System Preferences, then Location, and only then an individual link). I'm not sure this impedes usability, though.

I think the Mac's strengths here are not putting system architecture directly into the user's experience, direct and consistent (throughout both hardware and software) terminology, and a clearer location to find the settings.

There may be a downside when it comes to extensibility. And there are things accessible through the Windows interface which don't appear here. I don't know what this interface would look like, or if you must go to the command line for some advanced functionality.

Oddly, the Macintosh interface manages to pack an enormous number of settings into one window. I'm not sure this is specifically a usability point, but I found it relatively easy to do what I think is a very thorough set of screen-captures for the Mac interface, while I had more trouble doing the same on the Windows one.

What is my conclusion here? I'm not going to say which interface is "better". That isn't my point here. Here, I just wanted to demonstrate how differently these two environments have chosen to present their system configuration.

I've been doing some evaluation of the networking interfaces on Windows XP and Mac OS X lately. As I've been doing this, I've run into various inconsistency issues. Each time I notice one I find myself asking "Is this important, and if so, why?" I thought I'd share one example and use it to offer some thoughts on when and why consistency is important.

When I started working in the user experience field, I was very concerned about rigorous consistency. I'd often say things like "This needs to be consistent with that, or users will get confused!" I was involved in various efforts at writing UI style guides, and it is easy to approach those with an attitude of "everything must be just like this (or users will be confused)!".

As the years have rolled by, I've watched other folks come into UI design with the same attitude. So, I think it is a natural tendency. Consistency is relatively easy to identify, measure, and enforce. When there is no consistency, the situation is overtly bad: I still remember the chaos in the latter days of DOS. And a cursory use of command line interfaces on any *nix environment will show an amazing lack of consistency.

At the same time, I've also come to see that inconsistency sometimes doesn't affect the user, and sometimes is not even noticed (especially if the interactive flow is right and the inconsistency doesn't require the user to learn anything new) Given limited energy, there are more important things for a designer to do than get absolute consistency (though, your peers and management may be eager to criticize inconsistencies with alarming ease and vehemence).

So, let's talk about one tiny consistency example, and whether it is important.

When should you use an ellipsis (...) on the label of a button? Different platforms have slightly different rules. On Windows, the rule is found in the UI Guidelines:

If a command requires additional information to complete its intended action, and you use a dialog box to supply that information, follow the command with an ellipsis (…). The ellipsis provides a visual cue that the command requires additional information. ... However, not every command that results in the display of a window should include an ellipsis. Do not include an ellipsis for commands that simply display a window or view or change the existing view within a window. Similarly, do not use ellipses for commands that display a collection of objects or options, unless the intended action requires that the user select or confirm the selection of one or more elements of the collection. Also, do not include an ellipsis for commands that may result in a confirming message box

Consider this property window from Windows XP:

Notice the "Install..." button. This doesn't operate on the selected item above it. Instead it displays a window where you can choose something to be installed. Meanwhile, the "Properties" button just displays a window that shows the properties of the selected item and requires no input from the user. This seems consistent with the rules.

Yet, elsewhere in the exact same window, you can find this:

Why does "Settings..." have an ellipsis after it? Isn't that effectively the same as "Properties"?

Oh no! Inconsistency! It is the end of the world!

Well, OK, it is strange that there is this difference in the same window. But, is it really the end of the world?

For average Windows users, I suspect the presence or absence of "..." is not even noticed. It is just visual "noise" that they ignore among the flood of other "noise" in any computer interface. However, the ellipsis is a signal for more knowledgeable users.

So, for the knowledgeable users, is this inconsistency important?

In practice, I think knowledgeable users end up seeing the ellipsis as "Don't worry. If you click this, nothing crucial is going to happen without your having a chance to stop it". So, the presence of the ellipsis provides a sense of a reassurance. If it is used in a case where no action will be performed (e.g. in the "Settings..." case) the central concern of the user ("will something bad happen if I click on this?") is not violated, and so the user doesn't care. (In contrast, if no ellipsis is shown on a button that does display a window before performing some dangerous action ("Format") it may make the user nervous about clicking on it. An ellipsis on a button that doesn't display a window before starting a dangerous action ("Format...") would terribly violate the user's sense of security).

At this point in this example, we can say "Strict consistency isn't important, as long as you don't negatively violate the user's sense of security with the software." As far as the interactive usability of the software goes, that is probably true.

Yet, that statement bothers me. First of all, one of the benefits of consistency is that it allows someone to transfer their knowledge from one part of the interface to another. Put another way, it allows people to work in a new situation without learning something new (and, really, most people hate being asked to learn something new, especially when they are trying to get some task done).

Even if the user doesn't have to learn anything new, I'm uncomfortable saying consistency is not important. When I try to articulate why, I find myself thinking about the issue of "professionalism". When you go to a job interview, you tend to dress nicely. This doesn't mean that you will dress like that every day on the job. Nor does it say much about whether you are actually qualified for the job. Yet, if you don't dress well, it nonetheless reflects badly on you. In many ways, I have come to think this is an important aspect of consistency: If you do the same thing in noticeably different ways in different parts of your interface, it may not actually affect the interactive usability or the learnability of your product at all. But, it may reflect badly on the "professionalism" of your product, which reduces people's trust in it.

To summarize my point here, I'd say: Consistency is important, not necessarily because it improves interactive usability, or because it increases learnability, but because its absence suggestions unprofessionalism. Yet, essentially no users are so detail-oriented to care about small inconsistencies here or there. And the time you spend, as a designer, trying to get every detail perfectly consistent is time that you aren't spending on more important things (e.g., good interactive flow, or a good user model). Let the small details go, both in your designs and when reviewing other people's work.

(as a postscript to this example, I would also like to suggest that the rules of ellipsis use on all platforms are so complex and unnatural that almost no one can get them right. I certainly think that the rules articulated in the style guides are missing the point, that what I think users simply need is a reassurance that when they click on a button or menu item, nothing bad will happen. There may be a much better design solution for that need than putting "..."'s on various controls).

I've been reading the book Crucial Conversations (see the related web site for more info). It's about how to carry on a fruitful conversation when that conversation gets difficult.

Why is this relevant to the topic of usability?

In my experience, most usability folks work with folks in other disciplines. And of course those folks approach the shared project in very different ways. This, almost inevitably, leads to conflict. And the best way to deal with that conflict is to learn to deal with the conversations fruitfully.

I enjoyed this book a lot, because it seemed to offer a variety of good advice about dealing with these "crucial conversations" in a form that I think I can use.

Here is a diagram I drew for myself of the content of the book. I've added my own interpretations in places, and so a diagram you make after reading the book may be quite different from mine!

As wtih all such "self help" books, the hard part is going to be to put the ideas into practice. This is why I took the time to make the diagram... so help internalize some of the ideas and to give myself a cheat sheet. Before going into a meeting I can look at one part of the diagram and say "this is the skill I will practice today".

For me, personally, the thing I found most useful was a strategy for when I feel unsafe in a conversation. The idea they suggest is to override the stories I am telling myself about the motivations of the other people and present my side of the story... lead with facts, then present my interpretation of those facts. This sounds obvious, but it is actually remarkably hard to do in the heat of the moment.

I was having a conversation last night with my friend Alex Mckale, and somewhere in the middle of that conversation the phrase "It's not about usability" leapt into my head.

I think this came from a portion of a conversation where we were talking about two software companies. One delivers stuff aimed at consumers and has a reputation for being willing to deliver ugly code as long as it solves the user need, while the other has a reputation for delivering high quality code.

This lead me to quip, thinking of the former company which is doing well these days, "It isn't about the technology, is it?" And, of course, when you're not a programmer perhaps you realize that. It is the usual thing: people buy software in order to achive their goals, not to posess works of algorithmic art.

At the same time, though, it follows pretty naturally that no one buys a piece of software because it is usable. Again, they buy it to accomplish some goal. The usability of it is simply a way to facilitate reaching that goal, just as the algorithms and data structures are ways of facilitating reaching the goal.

If I've got a nail to pound in, I'd prefer to use a well-weighted hammer with comfortable grip, pleasing color scheme and a rich sound when it strikes the nail. But if none is available, I'll use a soil-encrusted stone and probably get the nail in just about as well.

What's my point here? I guess it's a reminder to myself not to take my line of work quite so seriously. We're all parts in the greater solving-user-needs machine. Do your algorithm poorly: unhappy user. Do the usability poorly: unhappy user. Don't solve the user's need: no user.

I'm doing some design work for the OpenSolaris Network Automagic project ( http://www.opensolaris.org/os/project/nwam/ ), which I think will end up on that site next week.

Some of what I'm looking at is how can we automatically configure network settings on a computer.

In the process, though, I've begun to wonder about some of the settings for my applications. For one prominent example, in my email apps I usually have to type in a bunch of information to set up the account: my email address, my incoming server, whether to use SSL, my outgoing server, what userid and password to use for that and so on.

Why do we have to specify all this information? Surely 99% of the users specify the same settings except for their identifier. Shouldn't the rest be able to be automatically configured?

So, the usage scenario might be like this: (1) Start new email client (2) It asks me what my email provider's identifier is, and I type in "email.frozboz.net". (3) The email client asks the server what email protocol to use (POP or IMAP or whatever), the name of the incoming server, the outgoing server, the authentication modes, the ports. (4) The email client stores these and then asks for my username and password to access my email.

You can get more comprehensive than just solving the problem for email, but I leave that as an exercise for the reader.

Really, my point is: at this point in our computing history, asking someone to do more configuration than typing in a name and password is akin to cruel and unusual punishment. I suspect that many things can be automated better than they are, and the more you can automate in this regard, the happier your users can be.

Now someone just needs to set up an email automatic configuration (Call it DACP for Dynamic Application Configuration Protocol) and get it into Thunderbird and some mail servers and then watch it gradually get adopted.

Several times this week I've heard people comment that they've made an "operator error". This means there was a problem with what they were doing on the computer, and they feel they (the operator of the software) made the mistake.

One of these situations involved me as the operator. However, often these cases are actually problems with the user interface in some manner.

At the risk of turning this into a "moan and groan" session about my own troubles, let me relate the story of this to you:

I have a domain name registered through www.godaddy.com. I was getting nice notices from them to my main email account telling me that the domain would be auto-renewed. Notice how nice and pretty these notifications are. And how relatively clear it is:

I was also getting notifications to another email account like this:

Plain text, with the not very clear title "Item Expiration Notice"... just what item is expiring? If you look at the text near the bottom, though, you'll see this is pretty important. My credit card was "bouncing". Of course, I didn't notice this (indeed, I barely noticed the text email messages after seeing the nice graphical ones, much less the significance of what I was seeing).

So, my domain expired, and it cost me much money to pull it out of limbo.

As I investigated what lead to this little problem, I discovered that godaddy has two email addresses for me in my account. One associated with the account as a whole, and one associated with my credit card. So, reasonably, they were sending notices about my credit card to one email account and notices about my domain being auto-renewed to another.

The puzzling thing to me is: why did they need two email accounts? Why not one? Is this a reflection of their internal structure (the finance department insisted "We can't use the other email account you have gotten from them. We need our own!"), or was the person designing this part of their web experience somehow thinking most people would want to have this info go to different places (I'm not at all clear why I put two different email addresses in these two. I suspect that if these notices had been going to the same account I would have been more likely to catch on to the fact that soemthing was going wrong).

Either way, I thought this was an interesting example of a common problem with user experience design. The interfaces, meaning the parts that one sees and interacts with, of each part of this system were good (well, perhaps the textual email message could be clearer!). But the overall user experience was disastrous for me. And it is so often true that the failures in user experience happen despite there being good interfaces at each step of the way.

I sometimes find myself wondering about the role of product and component names in overall user experience. Of course, these tend to be defined by marketing rather than "UI" people, and I think that's the right group to be giving those names.

At the same time, of course, they are part of the overall user experience. So, this is yet another one of those indications that everyone on a team needs to be on the same page when it comes to the user experience. It doesn't do much good for the interaction design to be delivering one flavor of experience, visual design to do another, the programmers a third, docs a fourth and marketing a fifth. (Unfortunately, I have yet to work on a project where this isn't happening to one degree or another).

I often find myself thinking of the names that Apple rolled out when OS X was introduced. Carbon, Cocoa, Aqua. Really, these are pretty meaningless names. Yet, they were catchy and once you were oriented about what they meant, they served as great handles. I also think of the wave of "Active Foobar" that came out of Microsoft for a while. I assume these were meaningful to folks tied into the Microsoft ecosystem (personally, I always found the "Active" prefix a bit distracting. and just as meaningless as, say "Sun Java" as a prefix).

No sizable company seems to keep its focus long enough to maintain a stable and predictable set of names over the long haul. I don't know if Apple is still producing things with elemental names, but I don't feel I've seen any. I'd expect the "Active" prefix has mostly been replaced by ".net" related things (yet, what is the naming family around that?)

Anyway, I think these names are actually reasonably important and probably shouldn't be changing based on executive-whim. It would be nice to see more well-thought-out names for products and subsystems that reflect the overall intended experience in some manner. I do feel like companies are beginning to get the sense that this is important (Sun, with its whole Share and Participation Age messaging does recognize that the company as a whole has to put some stakes in the ground to define what it is about).

I've come down with a fierce bug of some sort. It has been interesting to me that many folks feel (perhaps rightly, perhaps wrongly) that the primary transition vector for diseases is the hand.

One thing I did this week was comment on the design for the design for the Launch menu in JDS:
http://www.opensolaris.org/jive/thread.jspa?threadID=6399&tstart=0

Things like this interest me. Calum posted the call for opinions, and it sat there with no feedback. Then, I posted one comment and then lots of folks had comments had comments as a result of my comments. Sometimes with these things you just need to be willing to voice an opinion in order to generate discussion.

Now I'm going to go to sleep.

david

I sometimes use StarOffice on JDS. JDS has various rough edges which sometimes make me feel frustrated.

Today, I realized that one of those rough edges is that the buttons in some StarOffice dialogs are in a different order than the ones in most other apps on JDS. Consider these two dialogs:

The primary button (OK) of the StarOffice Character dialog is on the left of the dialog, while the primary button (Save) in the gedit alert is on the right side of the window.

Certainly not everything in the GNOME world is consistent with the GNOME UI Guidelines, so you could certainly argue that this is not an important detail given the other rough edges in the environment.

While this detail (for me at least) is not something I'm usually consciously aware of when using the product, my unconscious does seem to notice this. My unconscious whispers to me "I'm not sure why, but I seem to have to work too hard in this environment." I think this gives a real (though hard to quantify) sense of poor product quality.

Notice that in another reasonably popular environment where the buttons are in the opposite order of JDS, this button order seems OK:

Here, the StarOffice Character dialog has its buttons in the same order as the earlier one, while the message box from a text editor has buttons in the same order as the Character one.

I'm not part of the OpenOffice team, but I would guess that they decided: "We want OpenOffice users to have a consistent experience on all platforms. So, make the buttons the same on all platforms." This makes sense. If you were using OpenOffice in three different environments on your desk, you might indeed get frustrated if the buttons were in different orders in the different environments.

So, this brings us to a design question: if you were designing OpenOffice, which way would you put the buttons?

Personally, I would put them in the order of the environment (GNOME order on GNOME, the other order in some other environment). But, I think this is precisely the reaction that, as a designer, I must ignore. This is because s a user of the product, my opinion should not be weighted more heavily than any other single user of the product. I think that as a member of the product team, I would be obligated to set aside my personal opinion and ask: who is the product being created for, and what do they need?

That's an easy question to ask, but it is surprisingly hard to get the emotional distance from your own concerns in order to professionally answer it. In fact, perhaps OpenOffice is targeted primarily at users that simultaneously run the suite on multiple platforms. So the right answer may be to do exactly what it is doing, regardless of my own personal preference. When I watch some discussion groups on the net, it seems clear that some people don't understand the importance of ignoring themselves when doing design.

Of course, another design choice might be to provide an option that would allow the user to control the order. Yet, this also demonstrates another fact about how people use software: Users don't change defaults. It is, inexplicably, easier to write a long blog entry about something than it is to open up some settings window and determine if there is such a setting! Maybe I'll go look now.

A friend recently showed me the Apostrophe Abuse blog (http://apostrophe-abuse.blogspot.com/). It led me to realize that "apostrophe abuse" is just a usability problem in the design of our writing system. Isn't that an interesting way to think of it?

The misuse of the apostrophe character (using the possessive form "its" when one should use "it's" to indicate an abbreviation of "it is") is one of those small details which some people find very upsetting. The amount of unhappiness they feel in these cases invites me to ponder the human condition... our need for things to conform to our expectations and our frustration when they don't. But, that's a topic for a different blog.

Usually, when people criticise the abuse of the apostrophe, they seem to have the attitude that the abusers are somehow ignorant, uneducated, or just incompetent.

Perhaps they are.

Yet, as I read through this blog, I realized that this attitude sounds very similar to the attitude of some software creators: "That user isn't smart enough to use my software!" In the usability field, we see this kind of thing as a problem of the design of the technology, not of the users.

From this viewpoint, the misuse only indicates that there is a usability problem in the written language. If we were designing the language like we design software, someone would write in a report:

In our usability tests, 40% of the people put the apostrophe in the wrong place. When we explained the rules to them, they still got it wrong 10% of the time. Based on the quality metrics for this product, we recommend a redesign.

Indeed, the cause of this problem isn't especially difficult to figure out. Most of the time, you do mark possessives with an "'s". ("That is Sue's elephant", or "The designer's nightmare"). However, you don't mark pronouns in this way ("Jumbo is his elephant"). Exceptions to general rules are often (but not always!) invitations for people to make mistakes. So you might predict people would have problems with other pronouns (indeed, a9.com tells me 86,000 web pages have the wrong spelling for "hers". Google knows of 650K. So, the prediction seems supported). However, the problem with "its" is worse, because "it's" is correct in a different case. So, you've got a general rule with an exception to it, and a different rule which produces something which looks as if the general rule had been applied. These are very logical rules. But as is sometimes the case, what you can state simply with logic can't be applied by ordinary people in practice (we aren't logical beings, even though we pretend we are).

Note: The redesign of written English is left to an exercise for the reader (there are some interesting possible solutions. Share yours!). Unfortunately, the written language is like command line interfaces: once it has shipped, it is very very difficult to change it, so I don't know if we can implement any new designs very soon!

Anyway.

Recognizing this ordinary situation as a usability problem in the design of the writing system makes me realize that a certain amount of our time in school is spent teaching us to work around design flaws. For example, certainly the time spent memorizing English spelling must be an example of this. Perhaps the need to memorize mathematical formulas indicates a usability problem in that field. The years spent learning to play a violin must indicate something about the flaws in the design of that instrument (can you imagine buying a piece of software so difficult to use that it would take you years of practice and extensive tutoring to become proficient? Hmm. Maybe some Photoshop users feel they've done exactly that!)

Indeed, isn't it interesting how we celebrate people that are masters at working around some of these usability problems? (spelling bee champions and folks like Yoyo Ma come to mind). Perhaps life would be more boring, though, if there were no usability problems at all.

How do you persuade someone that the information gathered by a marketing organization, while valuable, isn't sufficient to do good user interface design work?

This week I spent some time reading an extensive document of information about our customers gathered by our marketing organization. It is fantastic information and I'm almost drooling as I read through it.

At the same time, I'm also gnashing my teeth, because it doesn't answer some of the questions I have as an interaction designer. This got me thinking about the problems I've had in the past convincing some part of the organization that just because marketing was collecting information, it wasn't the kind of information needed for good UI design. This is not to say there is no overlap, but just that they aren't identical needs either.

In the document I've been reading, there is a lot of information like:

Customer would like feature X

Customer has this-and-such problem with feature Y

Customer wishes Sun would do W with product Q

In general, the information talks about large-scale problems, wishes, needs for features and needs for lack-of-features. Of course, this is a good granularity for marketing, for this allows them to ask for particular things from engineering and then promote those things when they market the product.

Some of these problems aren't really user interface issues at all. Of those that are, I tend to need much more "environmental" kinds of information. What does the user tend to do when they use feature Y? Sometimes there's a mental model conflict involved in the transition. So one of the sytem models needs to be adjusted. Or, if the user wants feature X, where will they need to use it in their workflow? Often I need to know the general attitudes or goals of individuals using the software and that will inform how to design the interaction. This kind of information is often absent from conventional marketing research results.

Perhaps the answer to my first question is to observe that marketing research tends to look at features and how they fit into an overall business need, while user research perhaps looks at features and how they fit into an individual's needs.

I was driving to lunch with a coworker recently. She pointed at her purse and said "I just bought this purse. And look, it has a special pocket for a cell phone in it!"

Indeed, it did, right near the opening. Very convenient for storing and retrieving a cell phone. A little more conversation revealed that this was basically the reason she bought the purse.

Of course, with my programmer hat on, I think "wow! So I could design a purse with a bunch of little specialized pockets and people would love it." With my UI hat on, I know that's probably not true. In fact, many pockets would detract from the ease of pulling the cell phone out of the purse, which is a big part of what that pocket is for.

Later, she commented that she'd love someone to design a car that had a place to easily put her purse when she got in. And, indeed, when you think about it, where does one put a purse when you get in a car? The several people in the car talked about this for a bit, with the women all commenting that a feature like that would be a major factor in their decision about what car to buy. One even implied she'd buy such a car now if it had that feature.

A purse bought because it has a pocket for a cell phone. A car bought because it has a place to put a purse. On the one hand, this sounds crazy. On the other hand, it makes perfect sense. When all purses are approximately the same, when all cars are approximately the same, it is the small details which distinguish them. The same is true, no doubt, for everything else. What are your cell-phone pockets and purse-holders?

Many years ago, it seemed to me that usability positions were largely the same. Gradually, the usability field has subdivided (or, I've become aware of the subdivisions!) so that we now have at least user researchers, usability testers, interaction designers, and visual designers. Increasingly, I feel like I'm seeing the emergence of what I might call "emotional designers".

I've been at a couple talks lately where people have spoken of a product as involving functionality, usability and delight. Sometimes "brand" gets added to that list, but I think that "brand" is probably more a byproduct of those rather than another category. The "delight" aspect was sometimes spoken of in the past, but it is more prominent these days.

I became very aware of this today in a design meeting. We were discussing the design for a wizard. I was making the point that from an interaction design standpoint, the first several parts of the wizard were irrelevant to the user. The user knows they want to install something, so the whole "welcome to this wizard" panel, for instance, is really a nuisance. Indeed, the splash screen, welcome, and license agreement pages are things I think most people get through as fast as they can without reading them closely, so they're a detriment from a gestural viewpoint.

At the same time, my colleague was making the point that the presence of the welcome page provides the user with a sense of comfort and security. Something like "Ah, now I know things are under control, I'm not being pestered by the computer and I can proceed when I want to". He was right, of course. That emotional state is important. Wizards are usually a pain. Why add to that pain by immediately interrogating the user with a 'where should I install this" question?

Pleasantly enough, we eventually found a possible solution that satisfied both of us, so all ended well.

For me, though, the interesting thing was that one of us took on the role of arguing for interaction usability while the other took on the role of arguing for emotional usability, and this was a surprisingly easy separation to make.

I think we'll see more and more attention to the emotional impact of interfaces in usability circles as time goes on.

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)?