Hot answers tagged response-time
103
I'm the guy who did all the prototyping on Google Instant, and I attended >90% of the user studies we conducted at Google. (and I'm going to try not to be biased!)
We went through several iterations of prototypes based on our internal testing. What we found worked really well with the current implementation was that study participants either (1) saw the ...
60
To me, the basic logic is this:
It's better to have a fast app than a slow app. While there are many studies that show that faster applications provide better UX, it seems pretty axiomatic to me. I mean, generally in life if we want something done, then we prefer it to be sooner than later (with the exception of various aesthetic and, um, other activities ...
57
Accessory, not necessity
The background should be an accessory, not a necessity. If the background weren't there, it shouldn't negatively affect usability. An example of a poorly designed website that uses the background as a necessity is Project Swole. Before the background is loaded, there is not enough contrast to read the text. When I access this site ...
41
...would the shop designer want shoppers to enter and walk as quickly as
possible between shelves, or rather design the route so that shoppers
are encouraged to stop, look, turn, discover... etc?
Your analogy is flawed. Even if I walk slowly through a grocery store, my eyes are taking in thousands of pieces of information at a time.
I have a ...
30
Good UX because they asked a lot more people than you did. :-) There's a great write-up on Google's blog.
We knew it would take extensive
testing to find the right design, so
we ran through a sequence of
prototypes, usability studies (testing
with people from the community),
dogfooding (testing with Google
employees) and search experiments
...
26
Cant stand the thing.
It's too slow It can sometimes take a good few seconds for the page to update. When it does, you've continued to type, but you have just seen the gem of a result.. but oh no, it's now rebuilding the list again based of the latest garble of text you've entered - and your gem is buried in the haystack once more
It's very distracting ...
25
Absolutely in the yes camp on this. This is one important place that UX differes from UI, I think, because UI CAN focus on a particular page, how it looks, how it reacts. But the user EXPERIENCE is about more than one page.
The fact that a pure UX designer cannot influence the technical solution is no excuse. Page load times as such may not be part of the ...
24
If we ask UX-guru Jakob Nielsen it's 10 seconds. Longer waiting times could get the user to leave the program/page and do other stuff in the meantime. Supposing that something has gone wrong also depends on the users anticipation on how long a certain task could possibly take and the kind of task itself.
Original (1993): ...
23
The latest research I know of suggests 2 seconds as the new benchmark.
Personally, I don't think it's quite that black and white - the faster your page loads, the better. Some stats to support this:
In 2006 Google’s tests showed that increasing load time by 0.5 seconds resulted in a 20% drop in traffic.
In 2007 Amazon’s tests showed that for every 100ms ...
23
There are many things you can do in such situation. Two obvious things that come to my mind:
Provide some distracting animation (time goes faster when user is distracted, check the Foursquare's animation they've used in their iPhone app).
Show some funny quote, interesting fact or tip that could be if not useful then just entertaining and appropriate in ...
22
I guess this should follow the classic usability guidelines for response time.
0.1 second is about the limit for having the user feel that the system
is reacting instantaneously, meaning
that no special feedback is necessary
except to display the result.
1.0 second is about the limit for the user's flow of thought to stay
uninterrupted, even ...
20
I would like to address this issue from two different perspectives: User experience and ethics.
User Experience - From a UX point of view, slow load times = bad user experience. Users get irritated if they have to wait more than they think necessary. More than 10 secs, and the user will most probably lose all patience and leave. Jakob Nielsen studied this ...
20
You should try performing A/B split testing to see which group of users is more productive. The first group will be denied coffee, but the application loads instantly. The second group will be given coffee while it loads.
I would propose that the second group, despite the 8 minute delay will finish the days work first ;)
16
It routinely takes more than 10 seconds to load a webpage on my iPhone. And I wait for it. So does everyone else with a smartphone, a shockingly large number of web users these days.
Page load times matter, but putting a # of seconds on it is missing the point. If it's the timesheet software I have to use to get paid, I'll wait a minute for it to load! If ...
16
You should not forget about page loading time. Load time is key factor in conversion from visitors to readers / users, and slow pages are extremely frustrating to work with.
If the large image in question can't be replaced, you can mitigate the effects in five ways:
Most of the background image in your new design is covered by your content. Why not just ...
16
The general rule of thumb for usability is to start off with no feedback, but to then display some busy indicator after 200ms, and if the process normally takes 5 seconds or more to present a larger feedback element (usually with a time elapsed timer, but preferably not with a progress bar unless you're very sure how long it will take). If something is ...
15
Hard Limits
In the 10ms-5ms range you're running into the refresh rates and response times of pixels on your monitor. Many monitors are limited to 60Hz (17ms refresh). You're also getting close to limits of visual perception. We take around 100ms to direct our eyes to something new that has appeared on screen.
Noise
The difference between a compile ...
15
Users hate slow UIs, just as they hate slowly loading websites. Pop in, fade out.
Your users are not here to admire your application. It's just a tool to help them achieve a goal, and when that's done, it doesn't matter how pretty the app - they're out of there. Now, that doesn't mean you should strive for dull, grey, boxy interfaces. But it does mean ...
14
But of course, Yes! You can never ever underestimate the value of a good cup of coffee. You know for a fact that coffee is the number one most important thing in an office which could make the office worker succeed or fail, at least according to Baltimore Business Journal:
The office coffee is more important than it seems …
workplace experts say that ...
13
For the 'input lag' part of your question, I still use the rules of thumb found in Nielsen's Usability Engineering:
The basic advice regarding response times has been about the same time for many years [Miller 1968; Card et al. 1991]:
0.1 second is about the time limit for having the user feel that the system is reacting instantaneously
1.0 ...
13
I don't like their implementation of instant results.
I love filtering results when the list is a regular font size and can only become more exact with the more text provided to the filter itself. (e.g. taking a list of 300 items and after 6 letters showing only 4 results.)
My major beef with Google's implementation is:
The update area is too big, the ...
13
Time is only one of the factors that affect whether an app feels responsive. However there are decent guidelines that give you a rough idea of how people perceive response.
Jakob Nielsen has written a good article on Response times that I use as a rough guide. It states that:
0.1 second is about the limit for having the user feel that the system is ...
12
US Department of Defense Design Criteria Standard - Human Engineering MIL-STD 1472F Section 5.14.9 and Table XXII requires that "Sketching" have a response time of 0.2 seconds "from input of point to display of line." That's a minimum standard of performance, so it should correspond to your worse-case conditions.
Like a lot of standards, I believe much of ...
12
OK design, but not necessary:
It saves the user a click for dismissal, but if the user happens to miss the message, she might feel forced to re-open up the subscription form.
No matter the time frame chosen, there will probably be three groups of users:
less experienced users that find it dissappearing too fast,
target group users that find it ...
12
I can't recall the study, but it has been found that the perception of speed is heavily effected by the time to first action.
So my suggestion is a 4th option:
Load the bare minimum that is needed for your customers to see the app and decide what they want to do. Basically what you've described as option 2.
Automatically put the other modules into a ...
11
In this Google Analytics blog post from this past April, Google shows mean and median site speeds world wide:
Important and of note here is that this is 2012, and site loading speed on mobile is a critical factor in measuring the responsiveness of your site.
Based on these worldwide results, it would probably be advisable to target your website to be ...
11
I think the slider's acceptable, but you should lead with the benefits, so it looks something like:
Faster Running Time |-----X---|---------| Better Quality
People are smart enough to understand they're sacrificing one for the other, or at least not dumb enough to think they're going to get both.
10
I would say no.
The slower a page is, the more efficiently I try to use it.
That means that for a slow page I do little to no exploring. Once I realize that the page is annoyingly slow, then I will actively avoid clicking on things that seem interesting unless I it seems really really really, really, interesting.
The faster the page is, the more ...
10
If at all possible, Asynchronous processes can be wonderful depending on what the slow part is. If you can keep the client-side GUI "live" instead of halting all use of the system between actions, your system can feel much faster and less frustrating.
As an example, I recently constructed a data-driven application which needed a responsive UI but needed to ...
9
I've always been told that a delay of 100ms is generally not perceivable. An answer in a similar StackOverflow thread says:
The 100 ms threshold was established over 30 yrs ago. See:
Card, S. K., Robertson, G. G., and Mackinlay, J. D. (1991). The information visualizer: An information workspace. Proc. ACM CHI'91 Conf. (New Orleans, LA, 28 April-2 ...
Only top voted, non community-wiki answers of a minimum length are eligible
