One of my themes on this site lately has been the user’s perception of time where I have written about waiting versus occupied time and the psychology behind waiting. The gist of these articles has been to convey how retail and other industries manage customer wait times or convert those wait times into occupied time. I have promised to follow-up these articles with practical examples of how we can apply these principles to computer, web and application interfaces. In this article, I do just that taking you through the first part of a series in which we’ll delve deeper and deeper into how we can design interfaces that are perceived as being faster or leverage user tolerance for delays. This particular piece focuses on the representation of time in systems and software.

It is inevitable the user will have to wait at some point in time for a process to complete or a page to load. Perhaps in the future we’ll have instantaneous response in systems. But as of the writing of this article, load times, data retrieval, installations and downloads all take between a few and hundreds of seconds. So how and when should this be represented so the user knows the system is working and not frozen? The answer to this will depend on how long our user will wait and what our ultimate goal is.

Let’s consider our end-user for a moment and what they might need to know. Generally, there are three questions your user may wish to answer:

• How much time will this take?
  • This is useful if the user needs to calculate whether they can afford to start the process or not.
• How much longer will this take?
  • This is the most common question the user will want answered because they are in a waiting state at that point.
• How much time will did this take?
  • This is mostly useful for benchmarking or some similar situation where the user must know how long a particular process actually took.

We are generally not concerned with the third question. The first question, however, addresses the estimated length of a process so the user can figure out whether it is something they can start and come back to later or if perhaps they must wait until after their next meeting to start the process. In some situations, the user can hit the button, walk off to the office cooler and kill some time while a scan or installation completes. Other processes may need “shepherding” as they progress. All of these scenarios are cases where knowing the prospective reporting of time can be useful.

The second question comprises the majority of time reporting in systems and software. This is the time where our user is actually waiting. And as I have written before, waits can be excruciating for the end-user – especially when they don’t know how long they will be waiting.

There are generally two ways to report the amount of time remaining or estimated for a process – visually or textually (or both).

Visual indicators usually take the form of:

• Busy animations such as spinners or spinning hourglass Microsoft used to use
• Progress bars

Textual representation can take the form of:

• Elapsed time or how much time has passed
• Time remaining until task completion
• Work units remaining such as “1017 of 3043 files scanned”

Often, interface designers and developers will include both textual and visual indicators such as a progress bar with textual indication of time remaining. But when should you use a busy animation versus a progress bar or textual indication? As a general rule of thumb, the following guidelines are best practice.

0-2 Seconds = No Indication Needed (generally instantaneous to the user)

2-5 Seconds = Busy Animation,Spinner or Spinning Animation

5-X Seconds = Progress Indication Needed,Progress Bar or Visual Indication of Start & Finish

10+ Seconds = Progress Indication & Cancel Button,User Should Have Ability to Cancel Process

There are instances when the busy animation is perfectly appropriate. But as users, we tend to become impatient or suspect system hangup if those animations appear on screen for more than about 5 seconds. The progress indicator with a textual estimate of time remaining is most appropriate in situations where the wait will last longer than 5 seconds. But how to estimate the time?

Time Units vs. Work Units – time units are great when you have a rough idea of how long a process will take. They are less ideal when the process length is not well defined or the estimate can change during the process. In such instances, you will most likely want to use work units as noted above where the number of files transferred is given or the number of files scanned is reported.

Time units do not have to be exact. In fact, you really don’t want to report there are “12 minutes 32 seconds remaining” in a process. Reporting right down to the second can be torturous. Steven Seow discussed this in his book and uses human reporting of time as an analogy. When you are asked how long you were at lunch today, you don’t reply with an exact number such as “43 minutes,” but rather “about an hour.” Seow suggests the use of time anchors – round numbers we often use to estimate time – and provides a matrix to use as a guide.

Seow also provides some guidelines on using time anchors:

• Time Anchors are time estimates under an hour (1, 2, 3, 5, 10, 15, 20, and 30)
• Use the Time Anchor Matrix to express ranges
• Never skip over a number when representing ranges
  • Examples: “Installation will take 2 to 3 minutes” “The download will take about 30 seconds”
• Ranges prevent users from holding us to exact numbers (or at least they are less likely to do this when given a range)
• Use anchors for countdown units in timers

Putting all of this together is pretty simple. If the process will take less than 5 seconds, you can just use a spinning beach ball, spinning circle or some other busy animation. If the process lasts longer than 5 seconds, you will generally want to use a progress indicator (such as a progress bar) and time anchors to give the user a rough estimate of how long the process will be. There may still be a wait, but the user will not have their attention called to an exact number or hold the system to that exact number.

In the end, this is truly about smoothing out the waiting process for the user. Using these techniques will not magically turn your users into Zen Monks with infinite patience. But these changes (along with other changes I will write of) begin to give you a synergistic effect where the sum of the small changes equals far more than the sum of their individual parts. It’s the small changes that matter to users in many instances. This has recently been written of in Dan Saffer’s book, Microinteractions. I recommend checking out his work if you are skeptical of the small changes herein making a differences.

Keep checking back as I continue to write on the perception of time. I’ll be including more interface design techniques to mitigate user wait time and tolerance.

My next article will focus on time units and 5 rules to ensure you do not violate.

Pocket Watch image used courtesy of Alexander T Carroll, Wikimedia Images:

http://en.wikipedia.org/wiki/File:Omega_pocket_watch.jpg