On several implementations I've worked with, loading times can be as high as four seconds for the start page. When all reasonable options are done, is it possible to distract the user to make the application seem faster than it really is? In short: If you can't improve loading time, is distracting the user a good technique?
I'm assuming this question was incited by: How and when should you use animation in your application?
I definitely do believe that if loading time cannot be improved, distraction is a good technique.
github.com , as well as the popularity of having interlaced .png's. Maybe the term "distracting" would only apply to stuff below 750ms, and after that, you're essentially letting the user know, "Hey, we got your input, and we're working on it." E.g. If you give a user an old computer running Windows, and ask them to open up a shortcut on the desktop, most people unfamiliar with the UI will begin to mash the icon furiously when the app takes a few seconds to load, similarly, if a user prints something, and no sound is made by the printer after a handful of seconds, the user becomes frustrated, and begins furiously printing over and over again, thinking that the printer didn't get their input.
It's like if you asked somebody a difficult math question, and their facial expression did not change, and they just stood silent for a couple of seconds thinking about the answer, before answering your question, you would likely think "Okay, they didn't hear me, I'm going to ask again". There is of course moderation, and if it takes less than 50ms it probably should not have an animation, as the user does not even notice the loading time, this varies based on your target audience, and the UI, and the animation, so take the specific numbers I gave you with a grain of salt, and play around with different times, to create a balance that makes your application seem both responsive and seamless.
As Marcos Ciarrocchi correctly pointed out,what users are more concerned about is the perceived time which it takes for your site or app to load than the actual time . To quote this interesting article which states that users are more concerned about how well and how quickly they can get a task then then worry about the initial load:
When we began our research, we thought we would find a strong relationship between page download time and usability: sites with faster download times would be more usable than slower sites. We also expected that users would be consistent in their ratings of site speed, and that these ratings would correlate strongly with the actual speed of the sites.
To test these predictions, we studied 10 different web sites over a 56 kbps modem. On these sites, we had users perform their own personal tasks; each user did something that was interesting and meaningful to her. No two users performed the same tasks on any site. For each of the sites, we had users rate how fast they felt the site was. We called the users' measures their "perceived speed" of the site. Later, we watched videotapes of the studies and measured the actual download times of the pages.
We started by confirming one of our hypotheses: all users rated the speed of the 10 web sites consistently; they thought Amazon.com, REI.com, and L.L. Bean.com were the fastest and About.com was the slowest. Despite having performed different tasks on these sites, users were consistent in their reports of perceived speed.
Our other finding, though, took us entirely by surprise. When we looked at the actual download speeds of the sites we tested, we found that there was no correlation between these and the perceived speeds reported by our users. About.com, rated slowest by our users, was actually the fastest site (average: 8 seconds). Amazon.com, rated as one of the fastest sites by users, was really the slowest (average: 36 seconds).
There was still another surprising finding from our study: a strong correlation between perceived download time and whether users successfully completed their tasks on a site. There was, however, no correlation between actual download time and task success, causing us to discard our original hypothesis. It seems that, when people accomplish what they set out to do on a site, they perceive that site to be fast.
When we thought about these findings, they made a lot of sense to us. If people can't find what they want on a site, they will regard the site as a waste of time (and slow). But, when users successfully complete tasks on a site, they will perceive their time there as having been well spent.
That said, a visual indicator which informs the user about the current state of the load and also provides him with information can be really helpful as it can help reduced the perceived loading time which is the factor by which users define their wait times. To quote this article from UX booth about the use of loading indicators and additional content to keep users informed and engaged
Hulu presents a slick Loading graphic while users wait for their video to appear. The animation keeps the users aware that progress is being made. In addition, Hulu also serves ads before starting videos. To keep users informed of just how much longer they will have to wait before their video starts there is a count down timer along the top. This timer serves two purposes: reducing frustration produced by waiting for ads and giving the user an understanding of the time frame left before they can see what they came for.
However if you are not aware of the exact wait time, providing a distraction can be helpful as long as its relevant or applicable to the end goal of the application. A good example is tweetgrader which provides a nice animation along with a funny text message to explain the searching process
The users really care only about the perceived time, which is not often the same as the actual loading time.
In that sense "distractions" are just another form of feedback, just like the progress bars and loading animations, but they reduce the perceived time to load. The Github example is really good and if you take a closer look you'll see that in the end of the page transition there is the old and dull spinning wheel.
However, this should be done only occasionally and should not be your focus: is like if people were forced to take long detours instead of waiting when finding a roadblock; you might end up thinking about making better and more fun detours while you should be focusing on fixing the roadblock.
Additionally, in this presentation Secrets to Lightning Fast Mobile Design, Mike Krieger, cofounder of Instagram, explains some things they did to make the app feel faster, in particular, they're "famous" for moving the bits while no-one's watching:
Bruce Tognazzini provides this guidance:
- Display a message indicating the potential length of the wait for any action that will take longer than 2 seconds.
- Communicate the actual length through an animated progress indicator.
- Offer engaging text messages to users informed and entertained while they are waiting for long processes, such as server saves, to be completed.
- Make the client system beep and give a large visual indication upon return from lengthy (>10 seconds) processes, so that users know when to return to using the system.
Football Manager displays tips during game setup, and when processing fixtures:
I have also seen game installers display imagery, and in some cases small games to play whilst the install is going on. I believe the Sims used to do this, although I cannot find a screenshot right now.
You can influence the perceived speed. In the following link, they talk about how OSX uses a technique to make their progress bars seem faster, by using "left-moving ripples that travel at a constant velocity". There are better techniques, which the video in this link illustrates:
There are also a couple of papers about it:
If the delay is caused by download times for large data objects you could try to prioritise the rendering of information answering the user's immediate need.
For example; on a job search system I worked on, we had long load times for some job searches, so we ensured that "X number of jobs found for your query" was returned rendered immediately, while a much larger JSON object of the actual job details was being loaded in parallel.
If that's not possible (e.g. the delay is caused by server latency) then you could go the LinkedIn mobile web route of using a loading graphic like spinner, though I have seen these (again on mobile) not test well as they don't give an indication of the remaining load time.
I think it's a great technique, I believe that subtle changes/animations in the UI can also help with making things feel more responsive than they are.
For example, if your doing something like extracting data which will take a few seconds, you could reveal a box saying what's happening, but show and hide the box with a subtle fade or slide in/out, which subconsciously buys you a second or two with the user.
Although ideally, if you can get away with the slow loading not being a problem/visible to the user, then that's much better IMO.