No matter how fast we make our processors run, "wait cursors" seem to be a much too common occurrence. Windows users usually see wait cursors as spinning hour glasses. It turns out that processor speed is not the solution for this problem, but fortunately, parallelism is.

It is time to put an end to wait cursors and other "please wait" indicators telling us that the user interface is completely unavailable on a system or in an application. I cannot overemphasize how strongly I feel about fixing this flaw in computers. The good news is, parallelism makes this possible to do by design. With the right design, we can see benefits with dual-core and expect to see improvements each time the number of cores increase until there are no more wait cursors!

Tabbing: Firefox Beats Internet Explorer
I spend a lot of my time in Web browsers, waiting. My favorite feature in browsers is tabs. I'm addicted. I use control-click over and over on links to open lots of tabs. Firefox is much better at letting me do this than Internet Explorer, because Firefox is available for more mouse clicks almost immediately after I use control-click on a link. Microsoft's browser, on the other hand, is designed in such a way that it stalls for too long to make my use of it comfortable. I tried out Safari as well. Safari on Windows, despite having plenty of "version 1.0" issues that prevent me from relying on it, is as good as Firefox in letting me control-click for tabs with reckless abandon.

Yet, all three browsers use wait cursors too much. After asking for many tabs to be opened, the user interface slows. The scroll bars stop working, even on tabs with all the content loaded, and menu items freeze up. Clicking to switch from tab to tab does not result in an immediate redraw, regardless of whether content is loaded or not. How much of this is the windowing system and how much of it is the application? I don't care.

Parallelism: Stomping Out Wait Cursors
Imagine designing a browser, or any application, where the user interface never waits. When the user requests something, another thread is given the work to do and the user interface continues to be responsive. If a repaint operation is needed, it is done immediately based on the most recently available data. If a menu option is desired, the options drop down and can be clicked upon. If something is pending, it is obvious what is pending and the wait is user-friendly. When something is completely impossible to offer as an option, the option is grayed out and a mouse over will cause a small pop-up explaining why the feature is temporarily unavailable. If stale data is displayed, it is still displayed with some intuitive way to convey that new data is coming. If a page is loading, instead of a blank white page, the old page is still faintly readable but obviously about to be replaced. When new content is refreshed into view, it is done smoothly, like a page turning or something else which is visually obvious.

All this is possible with parallelism. The keys are:

1. Never let the user interface thread do anything that can block other work.
2. Use additional worker threads to get any blocking work done.
3. Never let key data needed by the user interface become unavailable.

The third point requires rethinking data structures. Instead of offering nothing to display while a new page is loaded, imagine always having a page to display even when a page is loading.

When we program this way, we will end up with a great user interface, worker threads to use parallelism and accessible data structures that avoid contention.

Let's design with the user in mind; let's eliminate the crutch of wait cursors. And, before this causes a rush on grayed-out buttons, let me suggest that graying out buttons be used as a last resort. If you do use them, come up with a plan to reduce your reliance on them over time. With no waiting as a user experience goal, we can see lots of improvements from parallelism.

Browsers, Microsoft Word and Microsoft Office
I focused on browsers because I could at least see hope in Firefox and Safari toward using parallelism wellsomething I do not see in Internet Explorer as a user.

That said, I depend on Microsoft Word and Microsoft Office heavily. My experience says that the Microsoft Word team has really focused on these key issues. They slipped spelling and grammar checking into the background, as well as using threads to update change tracking bubbles on the side of the screen. When I'm typing changes in a complicated document, Microsoft Word remains responsive to my input even if the display updates lag, such as the change-tracking on the side of the text, repaging, and other formatting adjustments. Likewise, the spelling checker and grammar checker will lag a bit at warning me of my errors if I'm typing fast enough. And printing stopped being a bottleneck years ago, a feature I still love in Microsoft Word (background printing).

Hats off to the Microsoft Word team; I'm impressed. My only request would be that someone from the Word team go visit the Microsoft Office team. Microsoft Outlook freezes completely solid frequently for me while waiting for HTML downloads to preview e-mail or updates from the mail servers. Outlook definitely has key data structures go offline from the user interface far too often. Too many "highly contended locks," to put it in terms of parallel programming. I had hoped Office 2007 would make everything better, but there is still a large gap between the responsive Microsoft Word, and the frequently freezing Microsoft Office. They are worth comparing to think about this issue, as much as comparing Firefox and Internet Explorer. These are solvable problems that require consideration at a design level in the applications.

No More Wait Cursors
I dare to imagine a world without wait cursors. This is one benefit of parallelism, and it cannot come too soon.