- Reactive Web Design: The secret to building web apps that feel amazing
- Improving Perceived Performance with Multiple Background Images
- True Lies Of Optimistic User Interfaces
- The UX Secret That Will Ruin Apps For You
- Fake it 'til you Make it CSS
- Why are we waiting?
- Our best practices are killing mobile web performance
- Why Performance Matters, Part 3: Tolerance Management
- Why Performance Matters, Part 2: Perception Management
- Why Performance Matters, Part 1: The Perception Of Time
- Experiments in Loading - How Long Will You Wait?
- The technology behind preview photos
- An Introduction to Perceived Performance
- More Weight Doesn't Mean More Wait
- Wait for It...
- Why Waiting Is Torture
- How to Make Progress Bars Feel Faster to Users
- The "Psychological" Speed of Mobile Interfaces
- The Perception of Speed
- Let Your Users Wait
- Progress Indicators Make a Slow System Less Insufferable
- Progress & Activity
- The Need for Speed
- Asynchronous UIs - the future of web user interfaces
- The 3 White Lies Behind Instagram's Lightning Speed
- UX Tactics To Make Slow Things Seem Faster
- Building interface previews with React
- Non-blocking UI's with interface previews
- Facebook content placeholder deconstruction
- Making Wait Times Feel Shorter
Podcasts & Videos
- Denys Mishunov on Deconstructing Performance
- Instant Loading: Building offline-first Progressive Web Apps - Google I/O 2016
- Asynchronous UI and Non-Blocking Interactions with Elliott Kember
- Dopamine Jackpot! Sapolsky on the Science of Pleasure
- Response time in man-computer conversational transactions
- Faster Progress Bars: Manipulating Perceived Duration with Visual Augmentations
- A study on tolerable waiting time
Demos & Examples
- Demo of "Reactive Web Design: The secret to building web apps that feel amazing"
- The Perception of Speed
- The progress bar illusion
- Demo of "Building interface previews with React"
- Reactive Design on Codepen
Weight does not need to increase wait
We can often (usually, even) deliver a usable representation of a web page's content very quickly.
If something is fast, it must be easy
Quick is cheap. (...) Good things take time and are worth waiting for.
Faster doesn’t always equal better
There’s a mantra in the software world that faster is better. Are there moments when intentionally adding a few extra seconds creates a better experience?
We are more concerned with how long a line is than how fast it's moving
Given a choice between a slow-moving short line and a fast-moving long one, we will often opt for the former, even if the waits are identical.
People who wait less than they anticipated leave happier
This is why Disney, the universally acknowledged master of applied queuing psychology, overestimates wait times for rides.
Occupied time feels shorter than unoccupied time
The experience of waiting is defined only partly by the objective length of the wait.
Accelerate the progress and avoid pauses at the end
Progress bars with accelerating progress are strongly favored over decelerating progress.
Increase the number of pulsations
A research study found that "the progress bar with increasing pulsation was more likely to be perceived as having a shorter duration".
Use backwards moving ribbings
A research study found that progress bars with backwards moving ribbings seem faster to users than forwards moving ribbings.
Making users wait too long is a user experience issue
If users get the feeling that your application loads too slow, they’ll grow impatient, and spend their time elsewhere.
What do you eat when you’re starving?
"Anything" is probably the correct answer. In other words, our expectations of something (...) obviously affect our appreciation of the outcome.
Faster isn’t always better
When an action we perform happens faster than we would expect it to, we may not appreciate the effort put into it. In more extreme cases we may think that if it happened too fast, maybe it didn’t happen at all.
Avoid using static progress indicators
While any feedback is better than none, static indicators should be replaced with another type of indicator.
An operation should only be represented by one indicator
For example, one refresh operation should not display both a refresh bar and an activity circle.
If the percentage of completion is known, use a determinate indicator
They give users a quick sense of how long an operation will take.
Perceived speed matters a lot
Speed is critical and can make a huge difference to user experience, engagement and revenue.
Interactions should be resolved instantly
There should be no loading messages or spinners. Requests to the server should be decoupled from the interface.
Users want to use your application without any interruptions
They don't give a damn if a request to the server is still pending.
Feedback is useful and doesn't block further interaction
Not all feedback is bad. Unobtrusive feedback that's actually useful to your users is completely fine.
Load Content Based On Importance, Not Order
If a lot of friends have liked something, load it first.
When reading a blog, a lot of people will click "next post". So you could get the next page ready before they even click it.
Work ahead of the user
One example (from Instagram) is that whenever you pick a photo to share, as soon as you pick it, it uploads it.
Feedback shouldn't depend on servers
What this means is that no matter what your coverage situation is, you still get the visual feedback of your action.
Use progressive image rendering
Progressive image rendering is when an image is loaded blurrily, and then becomes clearer as it finishes up.
Give the user something to do
If people have something to do sitting in front of them, they're much less likely to be grumpy that they're waiting.
Make buttons respond super-fast
All you have to do is make the button look pressed as soon as it’s pressed.
Interface should feel fast, regardless of network speed
Any action such as loading a new page or clicking a button should have an immediate reaction.
Don't block the parts that aren't dependent on the server
Which means that users are not forced to wait for the whole page to load before navigating away from it.
Client side rendering is a must
Interface previews would be very hard to achieve using the conventional server driven approach.
Separate placeholder elements from the real ones
Generally, their structure differs.
Test your designs at different internet speeds
Seeing how your app performs across slow networks gives you an insight into the degree to which interface previews should be used.
Give some indication of what is going on
This is exactly like putting a progress bar on a long action. Apart from the fact it's some fancy polish, it's great usability.
Waiting isn't positive, minimize it
Waiting means you're spending your time doing nothing because of something else that's out of your control.
Wait time presents us with is uncertainty
Uncertainty about when the wait will end (and indeed, in some cases uncertainty about whether anything is happening at all).
Absence of loading indicator lengthens perception
This means that without progress bars or some other indicators your application will feel slower to your users.