What's the longest acceptable delay before an interaction starts to feel unnatural/requires an error message?

Question

We have a scenario where we need to call an API so that the user can draw something on the screen. The following scenarios are possible:

1. API call goes quickly and is successful: user draws a new object on the screen with no obvious delay.

2. API call goes quickly and is unsuccessful (rare but can happen, e.g. if 3G data drops out for a moment): user tries to draw a new object on the screen, but gets fast visual feedback that this has not happened. At this point they can try again immediately and don't necessarily need an error explaining what happened or that they can try again.

3. API call goes slowly but is successful: user is able to draw an object on the screen but there is an appreciable delay (we hope this is rare, but we need to concede that it might happen). The interaction would feel 'laggy'.

4. API call goes slowly and is unsuccessful: user waits longer for visual feedback before eventually discovering that they need to re-attempt drawing the object.

We could get around the uncertainty of latency and API call success by letting the user 'successfully' draw on the screen in the client (i.e. making the interaction more responsive), and letting the API call and response happen behind the scenes. However this would necessitate an error message when the API call has failed: we would have to let the user know "yeah, sorry, that drawing on the screen you just did? Not so much."

So my questions are:

a) How long is too long for 'drawing on a screen' response latency?

and

b1) Should we prioritise making the interaction fast (i.e. execute it in the client and make the API call behind the scenes, with a chance of having to show an error message that says "uh, we kinda lied, you didn't draw that thing")

or

b2) accept that occasionally it will be slow and that users will just have to try drawing the thing again? (doesn't seem very onerous and will probably not happen very often)

Answer 1

Standards for wait times

Microsoft has published standards for what your software can/must do during the first few seconds of wait time.

You can begin reading the guidelines under the heading Is this the right control on this page (about progress bars) in the Microsoft Windows UX Guidelines. Please disregard that this topic is about progress bars, since the "Is this the right control" section actually links to the guidelines for the alternatives.

As you noted in a comment elsewhere on this page, Microsoft isn't too absolute with the boundaries between wait times that are short, acceptable, and too long.

And absolute values might be an unhelpful yardstick, because a lot depends on the context. There's plenty of research that shows that the duration of actual wait time and perceived wait time can differ greatly. If you can make people feel like something happened quickly, then you don't need to take the same measures that you would take if users perceived it to be quite slow.

Fluid standards may be more helpful

As a starter for additional reading, try Wikipedia on Time perception, search the Internet, or try the book Designing and engineering time by Steven Seow, or, for a more general interest, try Faster: the acceleration of just about everything by James Gleick.

What do I do?

Notwithstanding that I just recommended a fluid standard, I often tell developers this, as the line we cannot cross:

• Within 4 seconds the system MUST provide feedback. Ideally, the feedback is simply to Quickly Do The Task That The User Wants To Do.
• If it's longer, let's think of ways to trick the user, by giving them something meaningful to look at while the processing happens in the background, or in stages.

Answer 2

It seems that you're already leaning towards the second option there, and I agree with you. Causing delays is better than creating complete frustration.

Either way, users react differently to slow responset times, as Jakob nielsen puts it:

Response-Time Limits

The 3 response-time limits are the same today as when I wrote about them in 1993 (based on 40-year-old research by human factors pioneers):

0.1 seconds gives the feeling of instantaneous response — that is, the outcome feels like it was caused by the user, not the computer. This level of responsiveness is essential to support the feeling of direct manipulation (direct manipulation is one of the key GUI techniques to increase user engagement and control — for more about it, see our User Interface Principles Every Designer Must Know course).

1 second keeps the user's flow of thought seamless. Users can sense a delay, and thus know the computer is generating the outcome, but they still feel in control of the overall experience and that they're moving freely rather than waiting on the computer. This degree of responsiveness is needed for good navigation.

10 seconds keeps the user's attention. From 1–10 seconds, users definitely feel at the mercy of the computer and wish it was faster, but they can handle it.

After 10 seconds, they start thinking about other things, making it harder to get their brains back on track once the computer finally does respond.

http://www.nngroup.com/articles/website-response-times/

I suppose you could use these time frames to display throbbers or different messages as things load up, letting the user know what's going on and that the wait will pay off.

Answer 3

First, you might reconsider the framing of the problem. The way you described it, if the user draws an object but the server doesn’t receive it, then the object was never drawn. From a UX standpoint this is precisely backwards, a system-oriented way of thinking. UX is user-centered.

The system is not the authority, the user is. An object is drawn as soon as the user draws it. He performed all the right actions and saw all the right feedback, so the case is closed and the user’s job is done—no waiting involved. If the system isn’t up to date on the facts, that’s the system’s problem.

If the system can’t self-correct in a timely fashion, the user must be notified. But he shouldn’t have to re-draw anything, or perform any further action. Instead, the system should attempt to re-send the drawing. There’s no reason to punish the user for the system’s shortcoming by making him do the same work over again.

If the nature of the product is highly timing-sensitive and users need quick feedback, you could use a combination of well-timed animations for a “sleight-of-hand” effect (animations that take up time while latency-intensive operations are happening) and the “skeleton screens” concept (LukeW: Mobile Design Details: Avoid The Spinner) to cover over latency-related issues for a few seconds. This helps prop up the illusion of a flawless system in the mind of the user, and prevents him from worrying about technical details that have nothing to do with him.

Answer 4

I think it's vitally important there be minimal latency in operations like drawing (or any mouse driven operation), so I propose a third option: perform the draw operation immediately (on the client) but indicate that the drawn object is in a pending state. The pending state can be indicated by having the object grayed out or a special color or a special background or....? When the confirmation comes back from the server the object's visuals simply change to indicate "normal object/not pending".

The important things accomplished by this are:

1. immediate response to UI interactions
2. the status is very obvious (what's pending and what's not).

The user should be able to inspect pending objects (find out how long they have been pending) and possibly resubmit them.

Answer 5

Perceived lag = latency + framerate

Response timings described by Nielsen is something different than perceived lag. While waiting for a page to load, user is expecting to see some delay and is not providing any constant input.

While drawing a picture, user is providing constant input and is expecting immediate response.

• User is going to notice lag when one of these happens:

  • framerate drops below 12fps
  • latency is higher than about 200ms

If your requests are going to cause one of these to happen, you should choose an option to do it behind the scenes.

---

Latency

Humans are very sensitive to noticing latency and framerate. Users would start to notice that drawing is laggy even after relatively short delays.

There are multiple scholarly articles about a treshhold when latency becomes noticeable. Interestingly, this is different different for audio and visual latency. While for some people 100ms latency for visual output can be acceptable, 10ms makes it already difficult to play an instrument.

https://en.wikipedia.org/wiki/Input_lag Testing has found that overall "input lag" (from controller input to display response) times of approximately 200 ms are distracting to the user.

https://stackoverflow.com/questions/536300/what-is-the-shortest-perceivable-application-response-delay The 100 ms threshold was established over 30 yrs ago.

Framerate

https://en.wikipedia.org/wiki/Limited_animation For movements in normal speed, most animation in general is done "on twos," meaning each drawing is displayed twice, for a total of 12 drawings per 24 frames per second. Faster movements may demand animation "on ones" with a new drawing in each frame.

Answer 6

Besides handling the delay as it happens I think it would be good to let the user know of the connection quality early on. A good example for this is when calling someone on Skype. With this the user is prepared to expect a delay based on their connection strength rather than get caught off guard while they are working on something.