Proper timing in user interfaces often has more to do with the user's perception than with the actual passage of time.
They say the secret of good comedy is timing; setting up the audience so the punch line lands when it will have the most impact. When designing user interactions, timing is equally vital, but in this case you want to minimize the impact. When Erich Wolfgang Korngold received a compliment for his Oscar-winning musical score of the movie The Adventures of Robin Hood, he responded, "Madam, if you noticed it, then I was not doing my job." The user interface, like the musical score of a movie, is not meant to be the center of attention. Users have a goal they're trying to reach through the user interface, but their attention should be on that goal and not on the user interface itself.
Timing issues are sometimes an inevitable property of the application and other times are deliberate design decisions. In either case, those timing properties can make the difference between an Oscar winner and a dud. In this piece, we'll examine response times, flashing lights, idle timeouts, and how to manage situations where delays are inevitable.
Understand User Perceptions
Most peoples' actions are taken at a pace that seems natural to them. If you walk beside someone whose pace is a bit faster or slower than your own, you won't move as smoothly as if you're with someone who walks at your pace. It's not a question of being fit enough to keep up with the faster walker; you'll always feel more comfortable moving at your natural pace.
Interacting with a user interface can be similar. In the simplest case, a display that doesn't respond immediately to the user will lead to a bad user experience. I recently experimented with two cell phones. One had a far richer interface, implemented on a high-resolution display that used color and icons extensively. The second had a monochromatic display and lower resolution (and incidentally a much lower price tag). The more expensive color phone always had a slight delay in responding to key presses. Perhaps the number of CPU cycles required to refresh the display caused the delay, or maybe it was just sloppy coding. If I pressed several keys in quick succession, I could be as much as three keystrokes ahead of the display.
On the cheaper phone, the manufacturers were less ambitious in what they tried to display but could display it instantly—or as close to instantly as a user can perceive. This instant feedback gives the user a feeling of comfort and control. Imagine how unnerving it would feel to drive your car if all controls had a short delay before responding.
For the purposes of a usability discussion, an "instant response" is one that's fast enough that the user can't detect the delay. It has long been accepted and confirmed by experiment that any response quicker than 100ms will be perceived by the user as instantaneous.1
Experiments have also shown that when the delay can be detected by the user, they prefer a consistent delay. Users are more uncomfortable with a large variation in the length of delay, even if the average delay is shorter. The user doesn't want to save time—they want to feel comfortable.
Ironically, the more expensive but slower phone could achieve many actions in less time than the cheaper phone. The richer user interface allowed some actions to be performed in fewer keystrokes than on the cheaper phone. As with many relatively short action sequences, it doesn't matter how long they take, it matters how long it feels. The cheap phone leaves the user feeling better and therefore gets forgiven for demanding a few extra keystrokes from the user. To return to the driving analogy, consider a journey where you travel at 40MPH for 30 minutes and cover 20 miles. Compare that with driving at 60MPH for 10 minutes, followed by being stuck in traffic for 8 minutes, followed by another 60MPH sprint for the final 10 minutes. Although the second drive might cover the ground quicker, the frustration of being stationary for a while makes it a more stressful journey than the first. The principle that applies to driving the car or using the phone is that the user doesn't want to feel that something outside of their control is dictating the pace.
All the eye candy and fancy icons couldn't compensate for the constant irritation of waiting for the interface to catch up with the keystrokes. The total amount of time it took to make a call or send a text message isn't the issue. There's a comfort level in working at your chosen pace and knowing that the device is also comfortable at that pace. If the user is forced to pause to wait for the device, the device is setting the pace, which will always give the user a level of discomfort. User interfaces are like clothes. If they look good to the eye, it helps them sell, but unless the owner is able to feel comfortable, the product will not have long-term appeal. In a user interface, if you get the pace wrong, the user will never feel right.
Provide Early Feedback
Some tasks have an inevitable delay. Giving the user some early feedback, such as a key-beep, may communicate that the action was received, and the user will therefore be more tolerant of a small delay before the display reaches its final state.
Sometimes the delay is due to the CPU power required to generate a graphical display—maybe a graph of recent activity of a controlled process. Some graphics applications generate an image off-screen and then copy the entire image to the display in one operation. This technique reduces flicker on the display. In some cases, however, if the user can see the graph being gradually generated on the display he'll be more forgiving of the delay. The gradual build-up of shapes on the screen acts as the progress indicator.
Set Idle Timeouts with Care
There are timing issues other than raw speed that impact the user. Actions that happen at unexpected times can be jarring to the user. Timeouts are one source of sudden actions.
In the case where changing device settings requires multiple steps, it may be desirable to avoid leaving the device in a state where a setting has been changed but not accepted. Timeouts guarantee that the device will not get left in a state where a single final key press will accept some change that was partly entered some time earlier, possibly by a different user.
There are a number of problems with this type of timeout. One is that the user may be deciding what step to take next when the initial steps are canceled. Estimates for time to read a screen may be optimistic if the designer is assuming that the reader is familiar with the device. Even a long timeout of several minutes is not long enough if the user decided to consult a manual or a colleague. The user may get the device into a state that is confusing. By the time the local expert is brought over to see it, the device has canceled out of the unusual state. Another danger with a timeouts is that the timeout may occur just as the user is moving his finger toward the final key of the sequence. The user may not be sure which occurred first, the timeout or the completion of the sequence. He may be left unsure as to whether the changes he attempted took effect.
This last problem can sometimes be avoided by showing a countdown timer for the last few seconds before the timeout, so that the user can see that the timeout is about to happen.
Short timeouts can be very frustrating. I often go into my office to get a phone number, type it into my cordless phone and then walk to another room in the house to make the call. By the time I have settled into my armchair, the phone has decided to timeout my last action and I am left with a blank screen. The timeout removed the dialed number before I pressed the connect button.
The obvious way to avoid surprising the user is to never timeout at all. Unfortunately, in some safety-critical applications, an accidental setting change is too great a risk to allow a setting change to be partially implemented for an indefinite time period. Security issues often motivate timeouts. If I forget my card at the ATM and walk away, it's better that the machine does not leave the PIN validated indefinitely, since the next customer might decide to perform a few withdrawals on my behalf. Other timeouts for power-save modes are similarly unavoidable.
In some cases, the timeout is unavoidable because of the nature of the system being controlled. When a user turns on a projector, there's a short delay before the bulb has warmed up enough to provide an image visible on the screen. The user may think that the device failed to respond to the On button and press it again. Of course, if the button is an on/off toggle then the user has now turned the device off. This is a case where the user has to wait for the timeout to expire, in other words, for the bulb to warm up. It's important to provide some other feedback during that period, such as a flashing LED, and to try to predict what the users might do if they ignore the LED when they get frustrated at the delay. If it's likely that they'll press the on/off button again, that button could be disabled for this time, or separate on and off buttons could be provided.
Duty-cycles for Flashing LEDs and Text
The most common timing characteristic to program into a user interface is flashing LEDs or flashing text on a display. The rate of flashing will often reflect whether you want it to appear as an urgent flashing or as a more lazy indication.
A 50% duty cycle seems like a natural choice for the flashing pattern of an LED. You may wish to pick a different duty cycle when flashing text. If the text is invisible for the off portion of the duty cycle then the reader will spend half of the time waiting for it to reappear so they can continue reading. To make matters worse, many LCD displays have a "burn-in time," which means that when text is displayed by software, there is a short delay before it is actually visible to the user. On some displays, I've found that the same text will vanish immediately on request, so the resulting visible time is considerably less than 50%. Allowing for these two factors, I find that a duty cycle of about 75% when flashing text improves readability considerably, though the ideal figure varies depending on the length of the strings to be read and the type of display.
The personal computer is often the first point of reference for usability. One of the most crucial differences between designing for the PC and designing for an embedded device is that when using a PC, the PC is the center of the user's attention for extended periods of time. When something changes on the display, it's reasonable to assume the user is looking at it.
Many embedded devices are more loosely coupled to the user. My telephone answering machine has an LED that flashes when there's a message on the machine. The pattern is three seconds, two quick flashes, three seconds, two quick flashes. Sometimes I arrive home, glance at the answering machine to confirm that nobody had tried to contact me while I was out, and pay no more attention to the answering machine for the rest of the day. The problem is that a quick glance at the machine could take far less than the three seconds between flashes. So while I'm looking at the LED, it's off, which I interpret as meaning that there are no messages.
I've now disciplined myself to stare at the answering machine for several seconds any time that I am checking it. This is a case of the user adapting to the device, when it should happen the other way around. The pace of the actions that I take when I arrive home was being dictated by a machine that took too long to indicate its current state.
Respect the User's Time
The natural inclination of the programmer is to write software that requests information as it's required, and not before. This does not always match the best timing for the user.
Consider a calibration procedure that requires the user to enter atmospheric pressure. The pressure isn't needed by software until halfway through a ten-minute process. So, five minutes into the calibration procedure, the device stops and prompts the user to enter the atmospheric pressure. Realistically, if a procedure takes ten minutes the user will go for a break or work on another machine. It's very frustrating to return to the device to realize that a question must be answered to before it can continue. If the atmospheric pressure was requested at the very beginning of the procedure, long before software needed it, then the user wouldn't need to return to the device at the halfway point.
DVDs and DVD players provide an interface that shows contemptuous disregard for users' time. These devices sometimes force the user to watch an unwanted movie trailer or copyright notice. While the legal eagles might suggest that the copyright notice is important, I've never read a book that wouldn't allow me to turn the page until I had read the copyright page for ten seconds, and I certainly would not appreciate it if I had to look at it every time I picked up the book. Treating these fairly dubious legal or advertising requirements as more important than your user's time will always insult your user, so think carefully before forcing these "features" onto your customers.
As a parent, I often want to turn on a film for the kids and then return to cooking dinner. However, the interface forces me to wade through a frustrating ordeal when I simply want to press Play and have no further interaction with the device. Ironically, old-fashioned video tapes did allow me to press Play once, and required no further interaction.
When the DVD menu is selected, it takes several seconds to appear to allow some action sequence to set the scene. I'm sure that the designers thought this would be visually impressive, but it reduces the user's control and forces the timing priorities of the device onto the user. While the fast forward button will sometimes allow you to skip these sequences, only a minority of users will discover that feature. The lesson here is to always assume that the user is busy and that extra time waiting for the device to allow the user to continue is rarely appreciated no matter how important or impressive the information presented during the delay.
A case could be made that if I have set aside two hours to watch a movie then an extra ten seconds waiting for a menu to appear is not a significant cost in time. That argument misses the whole point about who is in control and who is setting the pace. It doesn't matter how much or little time is lost or gained. The important thing is that the user feels that he is the one setting the pace, and that he is the one in control.
Use Progress Indicators
For any action that takes between one and ten seconds, your device should tell the users that they need to wait, but there's no need to indicate progress as a fraction of the complete time. Beyond ten seconds the user will want some indication of whether the wait will be short enough for them to wait around or if they have time to attend to some other activity.
A timer that counts down the seconds is an obvious indicator of the delay. Unfortunately, the exact time of the activity is not always known. In a control application the device may be waiting to reach a predefined temperature or pressure, or the device may be waiting for a response from another device on a network. Progress bars don't necessarily require that the rate of progress on the bar have an exact relationship with the amount of progress being made; a rough indication of elapsed work is sufficient. In the case of waiting for a system to reach a target temperature, the progress bar may reflect the difference between the current temperature and the target temperature, which might not have a linear relationship with time.
One study on progress bars in the desktop PC environment showed that if the progress bar fills slowly, the user assumes that the PC is slow. If the same progress bar is filled quickly several times then the user assumes that the PC is very fast but very busy. This may make you inclined to animate the progress bar more quickly and let it fill repeatedly. If you do that, you then lose the advantage of a progress bar that fills once, namely, that the position of the bar gives an indication as to what fraction of the total time has elapsed.
In some cases, an animation provides an indication of progress without any indication of the amount of progress made. On character terminal interfaces to Unix systems, one technique was to create a spinning line by displaying the characters | \ - / in sequence; as each character replaced the last it provided the illusion of a dial spinning in space, which confirmed that the system was still running. I still use this technique occasionally on small HD44780-based LCD text displays. Another option is to show three dots (ellipsis) that erase and redraw themselves one by one.
If a GUI is available the animations can be much more sophisticated. On a medical muscle stimulator, we drew the image of a man doing sit-ups when the device was delivering electrical stimulation to the stomach muscles. Windows XP shows files flying through the air as documents are copied or moved.
It's a good idea to link the animation in some way to real progress. On Windows XP, you can pull out the network cable while copying files but the animation continues. The GUI is then giving the impression that some progress is being made when in fact the transfer has halted.
Animations have a distinct disadvantage in that the user loses the ability to see how far they are into the process. You could design an animation that also indicates the progress or you could show a progress bar as well as the animation. In some cases the completion time may be impossible to calculate in advance and in those cases an animation with no progress indication is your only option.
Be cautious about overusing animations. They're appropriate when the user is waiting for the device and not focused on performing another operation on the device. Constant animation or flashing can be distracting. A few years ago when Netscape and Internet Explorer were doing battle to become the dominant desktop browser, both showed a planet in a large animated icon on the top-right of the display. An application that spent most of its time waiting for data from a slow dial-up connection had plenty of spare cycles to display this animation. Once the novelty faded, the animation was a distraction to the users who would prefer to focus their attention on the web page being displayed. The designers realized this too, and the animation all but vanished from the interface.
Allow User Cancellation
When actions take more than a few seconds, it's a good idea to permit the user the option of canceling the activity. For some physical processes, the cancellation might not be able to take immediate effect, and in those cases some indication should be given that the device has accepted the cancel command. Short actions don't require a cancel option, and it can be irritating for a Cancel button to appear for an action that only takes a couple of seconds. I usually use a ten-second rule for deciding if an action needs a cancel option. However, this decision is also heavily influenced by whether the user can predict the state of the system after the cancel has taken place. If you chose to delete a number of records, the user can reasonably assume that if they cancel half way through the action then half of the records may have already been deleted.
Consider another example where a system is performing some self-calibration. If canceling the calibration means that the old calibration has been removed but the new calibration is not yet in place, then you're left with an uncalibrated system, which may be worse than the out-of-date calibration that was present at the start. In such a case, I would be inclined to not let the user cancel the action, regardless of the delay.
Placement of a Cancel button should be carefully considered in a GUI application. It is common to have Cancel button appear while an action is taking place, and then an OK button appear when the action is complete. The OK might be allowing the user to confirm the results of the action or it may be used to dismiss the current dialog. The Cancel and OK buttons do not both need to be available at the same time. A mistake I sometimes see is that the Cancel and OK buttons are put in the same location, so when the action is complete the Cancel button appears to become an OK button. This is bad practice. If the user is about to click on the Cancel button but the actions completes just before he acts on the button, he'll inadvertently press OK.
Anticipate Slow System Response
Applications that involve controlling something at a distance can have tricky timing properties because of the delay between the request and the response. The delay might be due to the speed of light if the Mars Rover is being controlled by NASA from Earth. The delay might be due to network traffic if controlling the zoom on a microscope located at a remote lab or hospital. Similar issues sometimes apply in control application with slow response time to physical properties, such as temperature.
When the user makes a request but the response is slow, it's tempting for him to repeat this request. One technique to reduce the problem is to make the commands absolute instead of relative. In the microscope example, the command might be to zoom in to magnify the current image by 2x. If the command is repeated then the image will eventually magnify by 4x by the time all commands have been processed. The command could be changed to an absolute command by instructing the device to go to a magnification level that's relative to some fixed starting point. So 100% always means standard size. The command to go to 400% will always give the same image no matter how often the command is repeated.
The second technique to employ in slow-response systems is to explicitly display the queue of commands. This allows the user to know exactly how many commands the device has to execute to catch up with the user. This could be something as simple as a barograph that indicates the number of pending commands but may not show the exact commands.
The most familiar example of such a queuing mechanism is the print queue on a desktop computer. If I request a printout but don't see it emerge from the printer, I might be inclined to request it again. But if the queue is visible, I realize that the job is being processed, so I'm happy to wait.
Observe User Behavior
When you finally get your design implemented, get out the stopwatch and observe real users at work with your device. It will amaze you at how slow they are at some tasks and how quick at others. Have a good time!
Endnotes
1. Nielsen, Jakob. "Response Times: The Three Important Limits". Excerpt from Chapter 5 of Usability Engineering, San Francisco, CA: Morgan Kaufmann, 1994. [back]
