My name is Dave Kachman and I have an iPhone 4. I’ve never met Siri. I type in a 4-digit password instead of scanning my thumb. I have never experienced LTE.
Most times, I despise the “spinny”.
Figure 1 - Animated GIF image of classic "spinny" |
The “spinny” is an animated GIF image that is commonly used to indicate when a web application is loading something in the background. As users of the web, we started to see our beloved “spinny” in many websites when AJAX was introduced (which allows websites to asynchronously take actions without reloading the entire page). These actions could sometimes take a fair bit of time, so there was a need to inform users that the site was doing something in the background.
This is all well and good, but only if the wait time is reasonable. As I have witnessed over the last couple of years, adding a “spinny” whenever AJAX is used is not enough for all users. This is especially important for those not using the latest and greatest technology or those in areas with spotty network coverage.
The idea of “reasonable wait times” is not new. Jakob Nielsen posted about reasonable wait times in his article from 1993. He notes that the human attention span drifts after about a second of waiting, which means progress feedback must be given to the user if they must wait longer than 1 second to finish. The human attention span begins to drift again with delays longer than 10 seconds, after which Nielsen recommends updating users more frequently with updates on how the task is going.
The Facebook app on my iPhone4 has given me the most frustration with respect to slow load times and minimal progress feedback (and I don’t seem to be the only one). Facebook’s recent v10.0 update attempts to address this specifically with one of the new features entitled:
“Improvements to make News Feed load faster, especially on older phones and tablets.“
An example
When I load up the app, I see the screen noted in Figure 2 for up to 30 seconds. This screen has no loading indications whatsoever. After the application chrome is loaded, a loading indicator is revealed in the centre of the screen as shown in Figure 3. This screen tends to remain unchanged for around 10-15 seconds on the initial load of the app.
On a positive note, as I browse through the newsfeed, a "Spinny" in the top bar (as shown in Figure 4) provides feedback that the app is loading. A second loading indicator is displayed when I scroll to the bottom of the newsfeed as a visual cue that another post is loading (see Figure 4). These loading indicators are displayed while the app is loading, which usually is between 3-8 seconds; well within the Jakob Nielsen's guidelines.
Unfortunately, sometimes when moving through the newsfeed, I experience a blocking scroll freeze (see Figure 5). The screen might look like a fully loaded and functional page, but the app is actually frozen and can remain unresponsive for upwards of 25 seconds.
User waiting? More Spinnies!
There are many ways to communicate loading status to users, but displaying a “Spinny“ alone won't satisfy impatient people. As Luke Wroblewski described in his experience designing the Polar app, inundating users with spinning GIFs tends to convert them into clock-watchers, which makes them pay more attention to how much time it’s taking to load.
Imagine seeing a page similar to Figure 6 for 30 seconds before everything loads:
Figure 6 - Example of viewing a page with multiple "spinny" indications on first load of a page
Potential Improvements
A small portion of the content (the updates section) has loaded, but the majority of the content is still loading. These areas display a “Spinny” with no indication of load time. Users can start to browse through the content, but page components will be pushed downwards as images are revealed and text appears. This motion tends to draw user's eyes, distracting them from focusing on content that has already been loaded.
Ideally, when faced with a delay greater than Nielsen’s 10-second recommendation, we have two options: update the user with realistic progress indications or implement custom loading indications that inform the user what’s happening in the background.
1. Communicate realistic progress
Sometimes, developers can accurately communicate how far we've come and how far we need to go throughout a process. In these cases, we can use the HTML5 progress element or an equivalent control to display a loading bar, updating the percentage throughout to show users exactly how long they will have to wait.
Unfortunately, some tasks make it impossible to determine progress throughout the process. With such factors as Internet latency, spotty mobile network coverage, and other related slowness issues, accurately estimating processing wait times can be challenging to get right.
If we can’t produce an accurate estimation of the amount of time remaining, an estimate should not be provided. It isn’t useful to users to provide an estimate that's wrong more often than it’s right.
There are other ways that don’t rely on estimations that can communicate progress.
a. Amount of items
If the amount of items is known beforehand (i.e. loading 4/30 images), noting which image the system is loading out of the current total helps gauge the length of time remaining for users.
b. Multi-step process
If there are several discrete steps that are performed during a process, these steps can be communicated to users during the process. We may not be able to communicate how long each step takes, but we can at least to show users how many steps remain.
2. Custom loading indications
There are many different approaches we can take based on the length of time, number of items loading on the page, or complexity of process.
Progressively modifying loading indications while the user is waiting for the task to finish can provide empathy to users or at least keep them entertained. If we’re following Nielsen’s guidelines, we can use a “Spinny” graphic for the first 10 seconds of process wait time, then update the user with a different type of message periodically at predefined points to keep them updated with what’s actually happening behind the scenes.
For example:
Time elapsed since request made | Message |
5 seconds | Loading, please wait |
10 seconds | Request was sent, waiting for a response from our servers… |
20 seconds | Still waiting... |
30 seconds | We haven’t heard back from our servers. You can either continue to wait or cancel the request and try again. |
This way, we're acknowledging that the process is taking a long time with progressive updates, and at timeout, new options are given for users to cancel and try again later. It is important to note that if a timeout occurs, the process must be terminated on the server side as well to ensure unexpected events do not fire after the user has canceled the request.
Sometimes these can be quite entertaining. An older version of the MIT mapping software (check it out at archive.org using the map arrows to navigate) used humorous phrases that accompanied each loading message like “Please wait…and dream of faster computers” or “Please wait… we're building the buildings as fast as we can”.
Users never enjoy waiting, but they certainly appreciate any effort that makes their wait times more tolerable.
Avoiding Spinny-itus is a worthwhile endeavor. Even though our devices and our networks are getting faster and faster, our appetite for information seems to increase proportionally. With more and more of the world getting connected to the Internet with smartphones, the issue of latency on smartphones is always something to keep in mind.
We owe it to our users to keep them in the loop if things are taking longer than they’re supposed to take. Transparency and setting proper expectations while our users are inevitably waiting is the best way to not only instill patience in our users, but will go great lengths to keeping customer loyalty and trust with our services and products.