This chapter is from the book
This chapter is from the book
This chapter is from the book
Couple of Whiles
Sometimes stating ranges or upper limits is not possible because the estimated time depends on factors that are too variable or too difficult to predict. One notorious example is accessing a resource such as a database over the network. Even if the network connection speed can be determined, factors beyond the connection speed can adversely affect the access to the database. The dilemma of not being able to predict how long something will last and the need to provide some time estimate commonly leads to the use of phrases such as "a few moments," "please wait," or "a while." This practice might not be the best approach because such phrases are highly ambiguous and do not provide users with any certainty or comfort about the process.
Time and timing-related terms, such as "a few moments" or "a while," can be problematic because they are subjectively perceived and heavily dependent on context, not to mention culture, language, age, and so forth. That is, it is unlikely that such terms are quantified and perceived similarly from one person to the next, between the service provider and the consumer, and between us and the recording on the phone that keeps promising that that someone will be with us "momentarily." The pain of being put on hold on the phone for a seemingly indefinite time really stems from uncertainty, and the cure then is to provide some certainty.
As an example, the customer service departments in some companies make it a practice to have staff answer a phone call as it comes but quickly inform the caller that she will be put on hold: "ABC company, can you hold please?" This practice works to a certain degree because it provides some certainty to the user that he or she has probably dialed the right number and has at least reached a live person on the line. Likewise, the user benefits from some certainty about any work being done even if a time estimate is not possible. The following are some remedies and implementations to consider in lieu of using ambiguous terms:
1. Give Non-temporal Information
The first remedy is to treat this issue as a progress indication. When the completion of the process cannot be projected and no status is available to the user, we essentially have a Class B scenario (see Figure 6.2) or a Busy/Working indication. Therefore, we want to do the exercise described in Figure 6.5 to find a way to move this to the lower-bottom quadrant to make it a Class C progress indication. In other words, we want to find all possible information and display the meaningful ones to the user (such as numbers of lines read, number of projects searched, updated queue information, compiling phase, etc.) as the process is ongoing.
2. Timers and Timeout
Although the elapsed time typically should not be used in the UI, it can be used under the covers to implement a mechanism that will respond to abnormal delays. This is found in many telecommunication devices, such as cell phones when the device will stop ringing after a fixed number of rings or a fixed amount of time. In the software world, we typically find such timeout mechanism in Internet browsers or some network-related solutions. The key in implementing this is to determine what actions to take at what time. The first step is to use data or models to map out the distribution of latencies and associate them with success and failure rates. For example, you might find that beyond 30 seconds of inactivity, failure rates are at 90%. In this case, you might want to provide a means for the user to continue, abandon, or restart the process when a delay goes beyond 30 seconds. As a relevant footnote, beyond ten seconds (captive class, see Chapter 4, "Responsiveness"), an "escape hatch," such as a Cancel or Retry button, is highly recommended.