Introduction

As I stated in Section 1.7 of Chapter 1, First Principles, a very important factor in determining the usability of software products or services is their responsiveness. Notice that I said "responsiveness," not "performance" or "speed." There is a difference. Explaining that difference and how to achieve responsiveness when performance is limited as it almost always is is largely what this chapter is about.

For the benefit of readers who skipped Chapter 1, I'll provide a brief definition of responsiveness, and distinguish it from performance.

Highly responsive software lets you know instantly that your actions were received (e.g., button presses, mouse movements), lets you estimate how long lengthy computations will take, frees you to do other things while waiting for a function to complete, manages queued events intelligently, performs housekeeping and low-priority tasks in the background, and makes use of idle time to anticipate (and precompute) your likely future requests.

Performance, on the other hand, has to do with how quickly the software computes and displays the desired results. High-performance software gives users their desired results quickly; low-performance software makes users wait.

The good news is that software can be responsive even when its performance is low. The bad news is that much of the software in today's market has both low performance and low responsiveness. Bad combination.

This chapter describes the most common responsiveness bloopers and explains why developers commit them. It is organized differently from the other bloopers chapters of this book because responsiveness bloopers are all closely...