flow|state

Situation normal, all fouled up

Sometimes an application treats a situation as an error when the situation is, in fact, completely normal.

For a good example of a poor user experience, consider Microsoft Outlook’s support for the IMAP mail protocol. The vast majority of consumers use the POP protocol to get email at home, which generally forces them to keep all their mail on one machine at home. IMAP, in contrast, lets you keep all your email on the server, where you can get to it from work, home and on the road. Most email clients -- including those found on cell phones -- support IMAP. Upon hearing of these wonders, most people will ask why IMAP isn't used more often.

While large portions of Microsoft Outlook are very well designed, there’s no escaping the fact that the Office team cares first and foremost about the enterprise market. Large enterprises have more money than you do. They use Exchange, and Outlook's support for Exchange is fantastic.

People who use Outlook outside of an enterprise struggle along with support for POP mail that hasn't improved appreciably in years. While POP isn’t great, at least Outlook's POP driver is reasonably solid. Outlook's IMAP driver, on the other hand, appears to have been left for dead in the jungle, where it was raised by apes.

Among its many deficiencies, the driver can’t properly cope if you use two different machines (say, at home and at the office) to check your email. This scenario is one of the reasons for IMAP’s existence, and most IMAP clients handle this situation gracefully: if they see another client is checking the mailbox, they wait for a while then try again. If you try to use Outlook this way, however, the IMAP driver throws up the following error:

Your IMAP server has closed the connection. This may occur if you have left the connection idle for too long.

Not only is this message a poor indication of what's actually going on, Outlook displays this message every few minutes until you shut down one of the two Outlook clients trying to reach the mailbox. Outlook even displays this dialog even if Outlook is already displaying another instance of the same dialog. This is insane. I can come home from a day of work and see, literally, a hundred of such errors sitting on the screen.

Somewhere, deep down in the IMAP driver, there's probably a core function that checks for new mail. It's a sure bet that if this function is unable to check for new mail -- if, say, another email client is already checking the same mailbox -- this function returns an error. The function does this not because there’s anything really wrong, but because the function doesn’t have any other way of communicating what’s going on. The developer who wrote the calling function assumed that any error result is a real error, so they wrote the calling function to punt things off to a general purpose error handler that displays a generic error message. The limited forms of expression in code have completely warped the top-level user experience.

That explains why the error dialog got into the product, but why did it stay? Clearly the simplest reason is that none of Outlook’s developers use the product’s IMAP driver themselves. The above error is exactly the kind of thing a developer will kill in five minutes if it's in the way of them doing their own work. It's reasonable to assume that the reason no Outlook developers use IMAP is because they rely primarily on Microsoft-supplied Exchange accounts for email at work. The rest of the world suffers at home because of this.

I use so many of Outlook’s PIM features that I could never go back to a pure email client, but if all you need is mail, I’d encourage you to try Mozilla Thunderbird, which has excellent IMAP support.

Outlook's clever modeless delivery of useful info

Microsoft Outlook, a dyed-in-the-wool client app, makes very effective use of a certain UI technique that comes up more often on web sites: whenever Outlook has additional information to communicate to the user, it does so in a modeless way by making room for the information in the window the user is working in.

For example, if you're scheduling an appointment over a time interval that contains other appointments, Outlook lets you know in a status area near the top of the main appointment window:

The "Conflicts with another appointment" message works so well because the information, which is clearly salient to the current situation, is delivered in a modeless way. A less thoughtfully designed client app would pop up a modal dialog to communicate the same information, getting in the way of the user and forcing them to dismiss the dialog before they could fix the problem.

That web sites handle feedback modelessly is taken for granted. Virtually all feedback regarding field validation in a web form is dealt with this way, typically as red text adjacent to the fields that require re-entry. A Win32 application like Outlook has to do more work than a web site to achieve the same effect, because Win32's facilities for layout are so primitive that the designers and developers have to handle all the layout themselves. Nevertheless, this isn't rocket science, and the technique is so useful that more app designers should consider adopting it.

Error message o' the week

I've been using del.icio.us for a while to search for things, and finally got around to registering so I could tag things myself. I tried to create an account with an "@" sign in the user name, and the site produced the following message:

you can't use silly characters in your username

Positive emotion from the point of first contact

An application can engender positive or negative emotions in its users at the very earliest point of contact. When interacting with an operating system, the earliest point of contact is often the logon UI. The way an OS treats logon UI can easily establish a good or bad impression in the user's mind.

A long time ago, if you typed an incorrect password into a Windows logon dialog, you'd get something like this:

Windows is clearly treating the situation as an error and, moreover, it clearly thinks the error is the user's fault. Later iterations of the OS soften this message somewhat. By Windows 2000, the message changes to:

The system could not log you on. Make sure your User name and pasword are correct, then type your password again. Letters in passwords must be typed using the correct case.

This is a big improvement (not sure why User is capitalized, though), but the tone is still stiff and a tad patronizing. By Windows XP's Home edition, things become much more conversational:

Did you forget your password?
Please type your password again.
Be sure to use the right uppercase and lowercase letters.

This is pretty good, and it's hard to think of how to make this message much friendlier. Apple manages to, though, in its OS/X logon dialog. Apple's solution deftly finesses the situation by avoiding the error message altogether.

If you don't enter the right password, the dialog literally shakes back and forth and the password field is cleared. A couple of years ago when a colleague showed this to me, I laughed out loud. The dialog is clearly shaking its head to say, "Nope!", and just as clearly letting the user know they have to try again. It does this all in a humorous way that engenders a positive emotion in the user and without having to play verbal games to avoid assigning blame.

The inscrutable purpose of Mac controls

I just got a new Mac for the first time in ages. I was a complete Mac fanatic at the dawn of the Macintosh age, but eventually moved over to Windows since that's where the action was. I've taken a look at OS/X numerous times, but playing around with a product for a short while isn't the same thing as sitting down and really trying to use it to get something done.

I'm constantly struck by how little effort OS/X Tiger expends in bothering to explain the purpose of controls. Most of the bundled apps include their own collection of beautifully rendered little widgets whose purpose is often difficult to discern. My favorite example is the little glass bead found in the upper right corner of numerous windows for expanding and collapsing the toolbar and sidebar:

The glass bead in the upper right corner surely represents some sort of high water mark for obscurity. No text or icon to detract from the purity of the lovingly rendered glass! Maybe hovering the mouse over it produces a little tip window? Nope. (Why the heck not?) The search box, at least, uses a magnifying glass icon to suggest its purpose, even if the icon is highly abstract in both visual representation and concept. It's hard to think of a control that communicates less about its purpose than this little glass bead. (But not impossible -- perhaps we should be grateful the bead is at least adjacent to the region of the window it affects.)

The new user looks at the control and wonders, "What the hell do you do?"
The control gives its stony reply: "If you must ask, you are unworthy."

Leaving dependent controls enabled

In certain types of UI such as wizards and forms, it's common to see UI like this:

Here the text box is said to be a "dependent control", because its enabled state depends upon the current selected state of the radio buttons.

In situations like the one above, I personally prefer a design that leaves the text box enabled at all times. Instead of using the state of the radio buttons to drive the state of the text box, the design goes the other way: the state of the text box drives the state of the radio buttons.

• The text box is always enabled but is empty by default.
• If the user clicks in the text box and enters any text, the second radio button becomes selected to let the user know that they have now implicitly chosen the second option.
• Clearing the text box implicitly selects the first radio button (but leaves the focus in the text box so the user can enter something new).
• If the user types something in the text box and then changes their mind to explictly select the first radio button, the (non-empty) contents of the text box are left as is. If the user goes back and changes the contents of the text box, the second radio button is again implicitly selected (as long as the text box is non-empty).

This lets the user who wants to enter something in the text box do so directly, without having to first select the second radio button. In my experience, this technique makes the UI feel faster, avoids frustration ("Why can't I type in the box?"), and doesn't suffer any practical downside.

Picasa Hello vs MSN Photo Swap

I recently played with two photo slideshow sharing products: Picasa Hello and MSN Photo Swap (part of MSN Messenger version 7). These two products both give people a way to show someone else photos over the net, but their UIs reveal subtle distinctions between their user models for this task.

The most interesting distinction for me comes up in the UI for determining who's showing photos and who's watching photos. Hello's model allows for free-form interaction between the participants. If you want to look at a specific photo, you can. If you want to let your buddy drive the action, you click a command called "Follow Friend":

You can see which photo your friend is looking at and -- if they want to follow your lead -- they can elect to follow along with you. In practice, this model and the resulting UI feels natural.

MSN Photo Swap, meanwhile, feels like what you'd get if you shared photos according to Robert's Rules of Order. One user has the floor, so to speak, and gets to hold on to it for as long as they want. When they see fit to cede control to someone else, they click a "Pass Control" command:

In practice, this model makes what should be a pleasant experience between friends feel dull. If I don't want to look at the photo my buddy is showing, I'm stuck. (Where is the "Filibuster" command?)

The rest of Picasa Hello's UI is likewise friendlier than that in MSN Photo Swap -- but the UI is moot. Hello is probably doomed as a standalone application.

Photo slideshow sharing is a feature, not a product. It only makes sense in the context of a larger framework for interaction over the net such as an IM client like MSN Messenger. I can't imagine telling someone that I want to show them some photos I took, but first they should download and install a client app that they'll never use for any other purpose.

Here's hoping Picasa Hello gets incorporated into something bigger, or that Photo Swap loosens up.

How many apps are there in that app, anyway?

Software product teams working on large products need to give names to individual application components just so they can communicate effectively -- but that's not a good reason to force a user to learn names for different parts of something that, to them, is a single entity.

A common example: a Setup app is a little application that helps install a bigger application. The software team needs to keep straight which application they're talking about (in specs, bug reports, etc.), so they give the Setup app its own name. The user ends up having to bear the burden of figuring out who does what. The following is a particularly egregious (and unfortunately very common) example:

So here we've got one named thing (Java Runtime Environment Setup) that's preparing another named thing (an InstallShield Wizard) that will help the user install a third named thing (Java). The user could care less about these other pieces that are involved, so there's no reason to confuse them by introducing these other components by name at all. All the user cares about here is getting Java onto their machine (and they may not really care about that either -- maybe what they're really trying to do is get a Java app to run).

The dialog could easily have said, "Please wait while Java is installed", or even just, "Please wait."

A UI sketch whose controls perfectly fill the window is probably too good to be true

If you're ever shown a UI design for a new top-level application window, be sure to notice whether the controls on the window happen to perfectly fill up on the available space. This is often a sign of trouble.

Many application windows are resizable. (If a top-level modeless window isn't resizable, it's a reasonable question to ask: why not?) A common mistake when designing resizable windows is to focus too much on some perfect window size that happens to show off the window's controls to best advantage -- a window size that few people other than the designer is ever likely to see. It's important to question how the window is going to respond when the user resizes it. For example, many users commonly maximize the application window they're working in. A surprising number of applications actually look awful when they're maximized on a typical large display: the additional space the designer didn't design for is either wasted or allocated to some control (often a text box or list box) that didn't really need it.

Progress bars that start over are almost useless

An app should never show the user a progress bar, fill it up, only to reset it and make them watch it fill up again.

Two-thirds done—or is it?

An app with a progress bar that resets will fail to deliver on the promise it has made. The app is saying, "Almost done! Almost done! Just a second more!", then saying, "Just kidding! There's still more." The user loses faith the process is anywhere near completion. For all they know, the progress bar is going to reset again, and again, and again. If a progress bar can start all over, there’s practically no value in having a progress bar in the first place. It's more honest in such a case to use a progress animation instead of a progress bar; at least that doesn't make any promises about when an operation will finish.

When an app has back-to-back operations that can take a long time, incorporate the progress for those operations into a combined progress bar. This can be done, for example, by assigning arbitrary percentages based on expected results. If the first operation usually takes about three times as long as the second, then the first operation can be defined to fill up 75% of the progress bar and the second operation to fill up the remaining 25%. This can result in a change in progress bar speed, but this still allows the user to derive more value from the progress bar, and maintains a sense a progress.