Betalogue

Two weeks ago, I wrote a post about a shockingly bad UI choice made by the Adobe engineers who developed the new Adobe Creative Suite 5 (CS5) series of applications. As I wrote in my post, when you do certain actions that require the user to wait until they are completed before he can resume his interaction with the software, such as opening a large file in Photoshop CS5, while Photoshop forces you to wait, it changes the mouse cursor from the standard pointing arrow to a completely non-standard “spinning wheel” animation based on the indeterminate wait animation:

(What’s non-standard about it is not the animation per se, but the fact that it is used as a cursor replacing the standard mouse pointer.)

Then last week John Gruber posted a link to my blog post on Daring Fireball, which prompted a number of readers to send me additional feedback by e-mail.

In addition, at the end of May Adobe’s own John Nack posted an article about an unrelated UI issue in Photoshop CS5 on his own blog. This prompted someone in the “Comments” section to insert a while-you-are-at-it note about the “hideous spinning bars” used as a cursor in Photoshop CS5.

This comment in turn led to a number of replies, including some from John Nack himself.

To my astonishment, it turns out that there are some Mac users who are actually siding with Adobe on this and defending the indefensible. So I figured it would probably be a good idea to provide a more detailed explanation of the reasons why this is a very bad idea indeed.

First of all, it must be stressed that no other application in the entire Mac OS X universe uses the indeterminate wait animation as a cursor / mouse pointer. That is, quite simply, what I mean when I say that this is “non-standard.”

In my view, if you want to introduce a new UI convention that absolutely nobody else uses, you have to have pretty compelling reasons to do so. Unfortunately, I don’t think that the reasons given either by John Nack or by the Mac users who have jumped to the defense of Adobe on this are valid.

And if you are going to introduce that new UI convention in the latest version of your suite of applications, the least you should do, in order to show that this is actually a well-thought-out choice on your part, is to apply it consistently across all your new applications.

And yet, what do I see when I try to open a file in Illustrator CS5 and the application forces me to wait? You guess it… the Spinning Beach Ball of Death (SBBOD), i.e. the very thing that John Nack says “indicates trouble.” Ditto when placing large picture files in a publication in InDesign CS5. I don’t see an indeterminate wait cursor there. I see a SBBOD. Does it mean that Illustrator CS5 and InDesign CS5 are “in trouble” where Photoshop CS5 is not?

Of course not. It simply means that this use of the indeterminate wait cursor in Photoshop CS5 is not a well-thought-out decision, i.e. not something that was properly debated by a group of UI experts at Adobe and agreed upon as the best choice for the problem.

And what exactly is the problem here for which the indeterminate wait cursor is purportedly a solution?

The problem is, quite simply, that, when you open or place a large file (or even a not-so-large file, as is the case in Illustrator CS5), the application makes you wait. And because the application makes you wait, it has to give you some visual sign that something is in progress and that you have to wait.

Is this a brand new problem in Photoshop CS5? Of course not. It’s a problem that is as old as Mac OS X itself, and indeed, arguably, as old as computing itself. For as long as computers have been in existence, there have been situations where the user is forced to wait until the machine completes whatever it is busy doing before he can regain control of the UI.

Since it’s not a new problem, the basic question to ask Adobe’s staff is the following: Why the need for a new solution? And why just in Photoshop CS5 and not in other CS5 applications?

Is Photoshop CS5 the only application in the Mac OS X universe that sometimes forces its user to wait? Of course not. Every Mac OS X application has this problem sometimes.

And for this problem, there are a number of conventional solutions in Mac OS X:

1. the SBBOD, officially called by Apple the “spinning wait cursor“
2. a progress bar (or “barber pole” bar if the amount of time really cannot be estimated reliably) in a modal dialog box
3. the old wristwatch or busy cursor from the classic Mac OS days, which is still understood by most Mac OS X users, even though it should no longer be used in Mac OS X

Is there anything in this list that suggests that yet another solution is needed?

John Nack says that the old wristwatch and the SBBOD “mean different things” and that the SBBOD indicates “trouble” whereas the old wristwatch used to indicate “progress.” Yet this simply does not square with the reality of the Mac OS X computing experience.

As I noted in my earlier post, Mac OS X users see the SBBOD all the time. They are more than familiar with it. And, while its persistence on the screen over an extended period is indeed a sign of trouble, its intermittent appearance during user interactions with applications is extremely common and quite obviously a normal part of the computing experience with machines that are not always as fast as one would like them to be.

Is John Nack really saying that all other applications (including other applications in the CS5 suite) that use the SBBOD to make their users wait are wrong? And what about all those other situations in Photoshop CS5 itself where the application forces the user to wait by showing the SBBOD? Is the SBBOD is indeed a sign of “trouble,” where does this leave us? In a state of constant worrying about Photoshop potentially freezing or crashing?

It is completely nonsensical. Either the SBBOD is a normal and conventional part of the user experience in Mac OS X or most Mac OS X applications are always “in trouble,” on the verge of freezing on us, and we should live in constant fear of losing control of our machine for good.

Now, I am not a Mac OS X developer, and so I do not know whether the SBBOD animation is something that is exclusively handled by the OS itself or something that applications themselves can invoke as a way to make the user understand that he has to wait. The Apple Human Interface Guideline about the spinning wait cursor is not entirely clear on this:

The spinning wait cursor (see Figure 12-1) is displayed automatically by the window server when an application cannot handle all of the events it receives. If an application does not respond for about 2 to 4 seconds, the spinning wait cursor appears. You should try to avoid situations in your application in which the spinning wait cursor will be displayed. The Spin Control application provided with Xcode can help you eliminate code that is causing this cursor.

It says that the SBBOD (the “spinning wait cursor”) is displayed automatically by the window server (i.e. a process managed by OS X itself) when an application is unresponsive. But it does not say whether application developers should display a SBBOD animation themselves when an process is in progress which prevents the application from responding to user actions.

On the contrary, it suggests that the SBBOD should be avoided as much as possible. This, to me, means that Apple feels that, obviously, applications should remain as responsive as possible at all times, and that when an application has no choice but to stop responding to user actions during the completion of a task, it should use a more informative visual clue—namely the progress bar.

This is not said explicitly in this guideline, but if you look at the complete list of “standard pointers in Mac OS X” on that same page, you will see that there is not a single pointer that is meant to be used for indicating to the user that he has to wait. It simply is not part of the standard UI in Mac OS X.

And how is that possible? Well, quite simply because, unlike the classic Mac OS, Mac OS X is a fully multi-threaded and multi-tasking operating system that is capable of handling multiple processes simultaneously. The wristwatch and busy cursors of the classic Mac OS were a standard part of the UI because the classic Mac OS had much more significant responsiveness issues.

Mac OS X is designed from the ground up as an operating system where the user should remain in control at all times. Of course, this ideal is not always achievable in practice, but it remains the ideal that all Mac OS X developers should aspire to, and that, I believe, is the main reason why there is no wristwatch or hourglass or anything else like it in the list of standard mouse pointers in Mac OS X.

And when you think about it, the best Mac OS X applications are indeed the ones where there is no need for such a cursor and the SBBOD itself appears very rarely.

In a properly designed Mac OS X application, if you really have to make the user wait, the appropriate visual clue is a progress bar, preferably with an option to cancel the process if it takes too long. There are numerous Mac OS X applications that do this.

The applications in Apple’s iWork suite, for example, all use progress bars when opening or saving large documents. Similarly, an application such as HairerSoft’s excellent Amadeus Pro uses progress bars when saving and opening files, because it quite often has to deal with large audio files that take a while to load or save.

If the temporary unresponsiveness is limited to a specific document window, the progress bar appears in a small dialog sheet attached to the window’s title bar, so as to indicate that other document windows are unaffected and that the user can continue to interact with them in the meantime:

If the temporary unresponsiveness applies to the entire application and the user really cannot interact with the application at all during the process, then a modal dialog box appears on top of all document windows and stays open while the process is in progress:

At no time does the mouse pointer change to anything else. There is no SBBOD, and there is no wristwatch either.

That, to me, is more or less the ideal that every Mac OS X application should aspire to. (In truth, the ideal would be that no process requires a progress bar, because no process takes long enough to require one, but unfortunately our machines are not powerful enough for this quite yet.)

Introducing a new mouse pointer instead makes absolutely no sense, and also fails to follow Apple’s own instructions on the matter:

Before you design your own pointer, ask yourself if it is going to add value to the user interface. Recognize that by doing so you are introducing a new, potentially confusing user interface element. If you decide you really need a new pointer, keep the following in mind:

• You need to indicate where the hot spot of the pointer is.
• Your pointers need to be able to work on older hardware that may not provide hardware video acceleration.
• If you create a custom version of a standard pointer, you need to also create new versions of related pointers. For example, if you create a larger arrow pointer you need to also create custom pointers for copy, move, alias, poof, and so forth.

Needless to say, I believe that Photoshop CS5’s adds no value to the user interface and is indeed a “potentially confusing user interface element.” In addition, contrary to Apple’s specifications, Adobe’s indeterminate wait cursor has no visible hot spot. Why does Apple require that the cursor indicate its hot spot? Because of course when they wrote these guidelines, the pointers that they had in mind were pointers for manipulating objects, not a pointer to indicate unresponsiveness.

The bottom line here is that there already is one cursor to indicate unresponsiveness in Mac OS X, and that cursor is the SBBOD. And, as Apple’s own guidelines indicate, the SBBOD should be avoided as much as possible. This means quite simply that indicating unresponsiveness with a mouse pointer should be avoided as much as possible. It should be kept for those situations where there really is a problem of temporary unresponsiveness due to the application being overwhelmed by the events it has to handle.

When the application is not overwhelmed and simply requires the user to wait because a given process is going to take a while and the application really cannot be used for anything else in the meantime, then the visual clue should be a progress bar, preferably with an option to cancel the process if it’s going to take too long. The progress bar should be displayed in a modal dialog whose modality is limited to the thing that cannot be interacted with while the process is taking place. In other words, if the modality is limited to a specific document, the progress bar should appear to a window-specific dialog sheet. If the modality affects the entire application, then it should appear in a modal dialog box on top of all document windows.

It’s as simple as that. Only companies such as Adobe and Microsoft stubbornly refuse to follow Apple’s own guidelines and established conventions in the Mac OS X world, with no significant benefit to their users.

(I am including Microsoft here because they too have managed to invent their own system for providing visual feedback to the user while opening a large file. They don’t use a non-standard cursor, but when you have a document window already open in Word 2008, for example, and you try to open another document that is an RTF file that Word has to convert, Word 2008 displays a progress bar for the opening of the new file… in the status bar at the bottom of the current document window! It is totally absurd, because of course the conversion and opening of the new file has absolutely nothing to do with the status of the current document window, and so that current document window is in no way a “parent” of the process of opening the new file. But that’s Microsoft’s way of handling modality.)

This entry was posted by Pierre Igot on Monday, June 7th, 2010 at 3:41 pm and is filed under Macintosh. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.