ThinkFlood Blog

Responsiveness may not seem like a usability principle on its surface — generally the solution is more about technical implementation than an elegant design or some principle of cognitive science — but who among us does not get frustrated from time to time when waiting for the hourglass cursor? More than mere annoyance, devices that are slow to respond can hinder our productivity and creativity — we lose our train of thought while we wait, and then it takes some time get back to where we were, if we ever arrive there at all.

People have been comparing the Macintosh and Windows operating systems for a couple of decades now, but to me one of the biggest differences between the latest and greatest of these (Vista and OS X) is responsiveness. Macs boot faster, launch applications more quickly, and generally respond to mouse clicks and keyboard input with a fluid-like simplicity that defines elegance. Most Linux distributions are also relatively zippy — even when running on yesterday’s hardware.

Of course we may be able to trace some of the slowness of Windows back to a lack of minimalism — after all, this is the operating system for all devices, from the cell phone to the supercomputer — but there is more to responsiveness than simply streamlined application code.

Without access to source code I have no real way of proving what I am about to say, but in observing the Mac OS, it seems to me that some of Apple’s gratuitous animations have more purpose than simply evoking a “wow” factor. For example, consider what happens when we launch an application. At the very least, the operating system has to load the application into memory, and in memory-constrained situations it also has to page out other applications to make room. Then there are application initialization steps (Adobe applications are notoriously slow here), which may involve caching information from other files on disk, opening network connections, or even initializing devices.

In the Windows world, when we launch an application nothing much happens right away — depending on the vendor, the software may display a splash screen, but generally we wait while the program launches. Even worse, in most cases the outline of a window draws, but the display freezes or slows while some preprocessing takes place before the rest of the screen is painted.

The Mac is a little different. An icon in the dock begins to bounce, and continues to do so until the application window comes up. And when the window appears, it draws to completion without an appreciable pause in the middle. Do Mac applications launch faster? Somewhat. But more than a faster launch, there are clues to us that something is going on. That is, rather than sit and wonder whether the application we have just tried to launch is in the process of coming up, we can see the bouncing icon and know that help is on way.

Now, I’m not a huge fan of the bouncing icon trick, but the point is that this action is a means of communicating with the user, which has the effect of making the whole process seem more immediate and responsive. Some may ask what the cost is. After all, we would not want to slow down the process further simply to make things look better, right? In fact, however, the things that take the most time during application launch (reading the program from disk, paging out other applications, opening network connections) require relatively little muscle from the central or graphics processing units — they are I/O-limited operations. Why not use a few of those spare processor cycles to entertain/inform the user of what is going on?

In fact, there are a handful of controls that we rely on for this kind of operation, such as the aforementioned hourglass (or wristwatch) cursor, animated spinning wheels/beachballs, and progress bars. Of these, I prefer a well-implemented progress bar, because it actually gives me an idea of how long I will need to wait.

In addition to these small animations, however, there is another point that I was trying to draw out, and that is the issue of screen refresh. Not only does it look poor when a window begins to paint but then freezes, it also begins to remind us of how applications look when they crash. To me, a half-painted window always seems to be a sign of application instability — an uneasy feeling that I could do without. Rather than rush to paint the outline of the window, why not provide the intermediate animation for a little longer, and then paint everything at once?

Responsiveness takes a backseat to many of the other usability principles, because it does not help us learn or understand an interface better. However, certainly a slow application can be the cause of much frustration and even confusion, so we should be mindful of this principle in our designs. At the very least, when our applications do require some extended processing or waiting time, we should provide feedback and status information to keep users informed.