Managing the Perception of System Responsiveness
by Paul Freedman
Designing and Engineering Time: The Psychology of Time Perception in Software, by Steven Seow, ISBN13: 9780321509185, ISBN10: 0321509188, Addison-Wesley Professional, 2008, 224 pp.
Steve Seow works at Microsoft Research and his new book, Designing and Engineering Time, reads like an extended presentation to software development colleagues (based on his doctoral research at Brown University). Over the course of 11 chapters and almost 200 pages, Seow writes about our perception of time and, in particular, our perception of system responsiveness to user input. For that reason, “designing and engineering time” is understood to mean designing and engineering the factors that bear on the perception of system responsiveness.
To that end, Seow presents research from the psychology and industrial engineering literature about human perception. For example, human reaction time—that is, the human response to a system-generated prompt—is about 200 milliseconds (and increases with age). Similarly, human attention span is about 10 seconds (which, as my 9 year-old nephew reminds me, can also increase with age).
Indeed, Seow suggests that how a system indicates (computational) progress to the user is both a “major” and “delicate” topic because the indicator should make evident what’s been done and, moreover, what still needs to be done. Here he introduces some useful rules of thumb:
- for time delays > 2 seconds, a binary progress indicator (“busy” vs. “done”) might be sufficient;
- for time delays > 5 seconds, the progress indicator should be continually updated; and
- for time delays > 10 seconds, incorporate an “abort” mechanism (that’s a consequence of our 10-second attention span).
Of most interest are the “techniques” presented in Chapter 10 to “manage” either the user’s perception of system responsiveness or the user’s tolerance to (inadequate) responsiveness.
In the first category, managing the perception of responsiveness, are suggestions to start processing the first user inputs as they’re provided, before all of the inputs are ready. In this way, processing can begin behind the scenes. In the same vein, the system can signal to the user that processing is complete even though some “clean up” continues to take place behind the scenes.
In the second category, managing tolerance to (inadequate) responsiveness, Seow suggests that the system provide overestimates of remaining time so that processing will be complete earlier than expected. (The fact is, as he points out in an earlier chapter, our sense of satisfaction has lots to do with performance exceeding expectations.) Another technique aims to make the user more confident in the system’s estimation of the indicated time delay (thereby making the delay more tolerable) by providing minimum and maximum values that are close together.
Seow’s book is an honest effort at “getting the word out” about the importance of responsiveness to user satisfaction, along with an introduction to the related research about human psychology. Still, although he specifically targets the software development community, Seow includes few real-world software examples. Instead, he gets by using more ordinary real-world examples, such as waiting for a table in a crowded restaurant. Surely someone at Microsoft would have a story or two (or 50) to tell, perhaps describing experiments in the company’s much-vaunted usability lab, which is supposed to bring software developers face to face with the cold, cruel world of real users.
Oh well, perhaps that will be part of a future edition.
Contact Paul Freedman at paul.freedman@simlog.com
