This chapter is from the book
This chapter is from the book
This chapter is from the book
Talking Time
To drink eight glasses of water every day is a recommendation some people heed religiously. The idea here is that there are health benefits, such as preventing dehydration, by simply drinking around eight glasses of water every day. This recommendation is simple until one starts to get technical about the volumetric quantity of glasses. Of course, the idea in using "glasses" is that it is easy and more practical to express than ounces or milliliters. Other than contexts in which precision is critical, such as brain surgery or aerospace engineering, for most parts of our lives we do not use or need precise measurements because estimations suffice. Perception is often inaccurate, and for most activities in life and work, it doesn't need not be. In day-to-day activities, we often rely on common objects when estimating and expressing quantity: The meatball was about the size of a golf ball. The new credit card-size digital camera is for sale next month. This way of speaking is common for estimating volume, mass, distance, and so forth.
For estimation of time, we are more likely to use proper time units (seconds, minutes, hours) instead of using references to objects or events. For example, not many people (at least in the Western culture) will state that they waited for table at a restaurant for about four to five times the amount of time it takes to boil an egg, or that the food took about 50 Hail Marys to be served. One possible instance of when we do not use proper time units is when we compare one duration with another. For example," By the time we got our table, we could have finished dinner at the other restaurant." Nevertheless, we're prone to simplify the estimation of time as we do for the estimation of other measures.
Time Anchors
Think about your last meaningful conversation with someone. How long did the conversation last? If you have to use time units such as seconds and minutes, there is a high likelihood that you will use whole numbers, like 1, 2, 5, or 10, to describe the duration. When we are asked to characterize durations of trivial events, we seldom give precise estimates such as 10.7 seconds or 5.17 minutes unless we are deliberately clocking the duration with a stopwatch or a wristwatch. Instead, we gravitate toward particular numbers to estimate durations. I call these time anchors because people tend to anchor their estimation to one or more of these numbers (see Figure 7.4). The term anchor is used to highlight the fact that although we know that an event lasted less than or more than five minutes, we still gravitate toward five when we have to verbalize an estimation.
)
Figure 7.4 Although the average person can detect differences between two durations, the tendency is to use time anchors to give time estimates.
To illustrate the effects of time anchors, consider that following statements:
- The conversation with my manager lasted no more than five minutes.
- He got up to the stage and froze for about 30 seconds.
- He was more than ten minutes late for the meeting.
Now consider how odd it is if these statements did not use time anchors:
- The conversation with my manger lasted no more than 4.3 minutes.
- He got up to the stage and froze for about 34 seconds.
- He was more than 9.44 minutes late for the meeting.
Using precise units (in contexts that are trivial, casual, noncritical, or colloquial) gives the impression that the given time estimates are exact, which either leads people to trustingly assume that you timed the event or invites them to verify the accuracy of the estimates given. If you know that your conversation with your manager lasted for 4.3 minutes, chances are you weren't paying attention, were you?
Time Anchor Matrix
For time estimations under a few hours, people tend to gravitate toward the numbers 1, 2, 3, 5, 10, 15, 20, and 30. That is, when asked to estimate a short duration, people are prone to using one or more numbers, such as "about ten seconds" or "two to three minutes," in their estimates. This is observable for durations in the magnitude of hours, but to a lesser extent. A quick way to remember these numbers is to express them in what I have called a Time Anchor Matrix (see Figure 7.5).
)
Figure 7.5 The numbers toward which people gravitate when expressing time can be easily remembered in the Time Anchor Matrix.
The average person can tell the difference between four minutes and eight minutes, so the matrix doesn't imply that we are only capable of estimating time using these whole numbers, or that we perceive everything in the world in chunks of time dictated by these numbers. Rather, it suggests that these are easy and practical numbers we are comfortable and confident using when we have to describe the length of time, particularly in impromptu and trivial contexts.
Why people gravitate toward these numbers is not clear, but it is highly likely that our sexagesimal (base-60) clock system has a strong influence. Another obvious influence is language and culture. In certain parts of the world, quantifying time in seconds and minutes is not typical. In some Muslim countries, time is commonly expressed relative to the five daily Muslim prayers. In Israel, time is commonly expressed relative to an hourly news broadcast.
Talking Time
Just as humans discovered that they can communicate with aliens in musical notes in Steven Spielberg's Close Encounters with the Third Kind or in mathematical languages in the late Carl Sagan's novel Contact, we can use the Time Anchor Matrix to communicate time estimates to the user. The three main flavors of time estimation are ranges, limits, and countdowns.
Ranges: Between X and Y
Time anchors come in handy when there is a need to specify a range of times to represent the possible durations of an event. This happens frequently when one or more other factors can influence the variability of the duration. For example, if we are confident that a particular process will take around four minutes, we can state (display in the UI) a range that spans over four minutes. Referring to the Time Anchor Matrix, we see that 3 and 5 are the integers that are the two surrounding candidates, and therefore we state that the process will take between three and five minutes (see Figure 7.6).
)
Figure 7.6 An example of how to use the Time Anchor Matrix to express a range of durations in the UI.
A rule of thumb for specifying ranges is not to skip over any successive time anchor. For example, we don't want to state 5 to 15 minutes because that skips over 10. The reason for not using wide ranges can be illustrated with a little imagination: Compare your response to the promise of two hypothetical cable companies, one promising that their service technician will be at your residence between 10 a.m. and 12 p.m., and the other stating that their technician will be there between 10 a.m. and 3 p.m. When the difference between two time anchors is too large, we begin to feel that the range could reasonably be tighter. Why a wide range would cause annoyance is possibly tied to a classic psychophysical principle called the Weber-Fechner Law that was mentioned in Chapter 5, "Detecting Timing Differences." Without going into detail, it is likely that using successive numbers theoretically makes it more difficult for people to perceive and "insert" one or more time anchors in between the high and low ends of the range.
Limits: Less Than or More Than X
There are two ways to express time limits, and each serves very different purposes. Lower limits tell users that a particular duration will take at least X amount of time. Upper limits tell users that a particular duration will not take more than X amount of time. You should use lower limits with care because it is essentially a warning of inevitable wait, and such statements are typically made to brace an individual for the wait or delay: The road trip to Vancouver will take at least three hours. The package will take at least one week to get to Singapore. The house inspection will take more than two hours. In contrast, an upper limit is a guarantee of completion: You will reach Vancouver by midnight. You will receive the package within the month. The house inspection will be done in one hour. Lower limits warn, and upper limits promise.
When it is not possible or wise to state a range, use the latter to state the longest possible duration in a statement such as "less than five minutes." When stating upper limits, round up to the next element in the Time Anchor Matrix. For example, if we are confident that a particular process will be completed in 7 minutes and 50 seconds, we'll state that the process will take under 10 minutes. Use the former when there is a need to warn users prospectively that a process will take a long time, especially if it is captive process when users cannot interact with parts of the application, operating system, or the entire machine until the process is completed. These are instances when you have some confidence that it will definitely take at least a certain amount of time. In such cases, state lower limits and do likewise in rounding up to the next highest time anchor. For example, if a process will take at least 3 minutes and 45 seconds, inform users that the process will take at least 5 minutes (see Figure 7.7). Underpromise and overdeliver.
)
Figure 7.7 Two illustrations of how lower limits (left) and upper limits (right) are used. Lower limits warn user of unavoidable wait, which functions to help users decide whether they can proceed with the process (spyware scanning, for example). Upper limits guarantee that a process will complete by a certain time, and thus functions well as a persuasive mechanism to encourage users to proceed.
The argument against using specific and precise numbers, such as 7 minutes and 50 seconds or even 8 minutes, is that when we use numbers that users are not accustomed to using (that is, numbers not represented by the Time Anchor Matrix), we risk making them hold us to what we apparently promised. This expectation is likely due to the fact that your statement is construed as one that has been made after rigorous timing and performance testing and that you have somehow locked down eight minutes with precision. In contrast, when you use the next higher integer in the matrix, ten minutes, it will more likely be perceived as a rough estimation because the colloquial prevalence of "ten minutes."
Remaining Time: Z, Y, X...
Unless there is a compelling need to report elapsed time (0:01...0:02...0:03...), it is always better to use a time-remaining or count-down timer (0:54...0:53...0:52...) if there is any need to show a timer at all. Reserve such use of timers to relatively shorter durations that are around ten minutes and shorter. Imagine watching a count-down timer from one hour: 1:00:00...0:59:59...0:59:58...0:59:57.... Obviously this would be too frustrating to watch!
Because a time-elapsed timer decrements like a clock or a stopwatch, providing it alongside a lengthy process is equivalent to inviting users to time the process, which will increase the chances of shooting yourself in the foot. Although the use of time-remaining timers is relatively and generally better, if the countdown is set to "tick" by the second, it can have the same adverse effect as a time-elapsed timer. This is where the time anchors come in handy. Instead of specifying every single second between 10 minutes and 0 seconds (10:00...9:59...9:59...9:58...), for example, express the countdown in time anchor units: (10 minutes...5 minutes...3 minutes...2 minutes...1 minute...30 seconds...).
As a footnote, when reporting remaining time, never allow remaining time to increase. At most, remaining time can remain unchanged momentarily, but it should never get longer, or worse, fluctuate. If your remaining time is prone to fluctuations, making remaining time difficult to predict, remaining time might not be the best progress unit to use.