UX design patterns for loading
pencilandpaper.io
pencilandpaper.io
I instinctively interpret them as a malfunction, not as a loading screen. A screen is supposed to have data. If it shows up empty, something has gone horribly wrong somewhere.
And as a developer, once it fills out, I get the secondary tinge of discomfort due to the nagging thought "this application has a bad handle on timing, there might be a race condition somewhere. Better do things really slowly and carefully."
In general though, 99% of the time, there should be no loading screen at all. My local airline shows a "Loading..." for several seconds even when doing things like logging in, and all I can think of is wondering what could take so much time. At this point a login should be a thing that can be done in a few ms.
the sudden shift is jarring, especially if the content is staggered
I think placeholder components are a step above “Loading…” because they hint at what’s to come and confirm that you’re about to go to the screen you expect. They also indicate that the user is experiencing a view change which is more specific than "wait while something is happening." It's more info.
As for why we need loading screens at all, plenty of developers make the mistake of never considering loading UX because they only use their own app from an optimal internet connection, so they never consider the experience from worse connections.
Sure, that works. If that's too slow, it should be made faster.
I mean, maybe that sounds odd, but even on say, a 10 Mbps connection you can load stuff at 1 MB/s, which means you can load 100K in 100 ms. That's plenty, considering in modern times we don't reload the whole page, so stuff can be preloaded and cached.
Eg, my airline has this "Login" link on the front page. If I click that, it pops up a little box, then for some bizarre reason has a "Loading..." inside that shows up for 2 seconds, then finally shows a field for username and password. This is on a 16 core CPU with a 1 Gbps fiber connection.
Like what is there even to load? It's just 2 text fields and a couple buttons!
If it's some tracking BS, well, that could be done asynchronously in the background.
I get that there still exist slow computers and bad connections, but in 99.9% of cases, there's no reason to have a visible load time on anything even relatively modern. We've long had the bandwidth to load more than anyone would care to read in 10ms, and the CPU horsepower to deal with it.
They show a white screen for half a second, which is usually enough to load the content. If the request takes too long, a spinner fades in.
They also, very conservatively, show partial- or skeleton screens. Crucially, these skeleton never animate, cause layout shifts or show filler content. They usually just show UI elements that would be there regardless of what the loaded content is.
I never even noticed the loading states until I started paying attention to them.
Effect: - no wait time, snappy interaction - better context around a new experience
Cost: - nothing
It reminds me that a solid portion of good design is not applying a rule or system, but creatively working between the cracks of known/obvious problem-solution pairs.
(I do not know where this story originated, but ever since hearing about this from one of my design professors I've noticed how many buildings put mirrors next to their elevators.)
More likely, the lift engineer (or team) is only allowed to "make this lift 20% faster" and is told to stay in their lane when they suggest non-lift-based ideas.
In all likelihood, the engineer is employed by a company in order to sell expensive lift upgrades, not mirrors or interior design services. And his boss has a target.
Sometimes solving the impact of a problem is much easier then solving the problem.
People would probably choose a system of 0-30mins delay with no info vs 0-60mins with info, if they know thats the rules. 'it'll be here within half an hour' is close enough to knowledge to get the uncertainty out the way which is a lot of the problem.
But if passengers don't know what the rules are or when (or if) the train is coming, and you'll get a lot less complaints and grumbling passengers with a 0-60 full info delay system then you do with a 0-20 with no info. In one you know the train is coming in 47mins. Annoying, but you can tune out for 30 mins, get a coffee, read hacker news, tell a friend you'll be 47 mins late etc. In the other it might be here in 2 mins or 20. You can't even nip to the loo without concern you might miss it. In the first instance you are mildly annoyed but you replan your time; in the second you're on edge for what turns out to only be 8mins, but a highly annoying and stressful 8 mins.
It's the uncertainty that's painful not so much the delay (for small-ish values of delay!)
These individuals tend not to have a whit of formal HCI education or real-world practice.
When you have little theoretical grounding and real world experience, all you have is examples from apps you spot in the wild to learn from. You don’t know what makes something work, and you have never seen it work yourself.
You might learn the wrong thing: that if some popular or financially-successful app out there has implemented a particular design pattern, that it must be a “best practice”.
It’s kind of like how most “how-to” articles, YouTube tutorials, and Udemy courses in software dev are made by junior devs.
A post about UX with a non-working UX.
I agree it seems to be used unnecessarily more and more now though.
Rendering placeholders allows us to load everything via REST. The data takes the same path every time, so, fewer bugs, streamlined way of loading data, plus kiddos love the simplicity of writing REST resources in Java. Also, each visual component can be programmed in isolation, encapsulating its own concerns, rather than having to mix all data into the MVC action channel. And isolation/encapsulation is good for reliability and sharing the work across a team.
One solution is to hydrate the initial HTML with the result of REST calls, but it has drawbacks.
I know it won’t mop your sorrow. It may just help to know there is a reasonable reason for that. I also find it infuriating to look at a page that says: “3, 2, 1, Done! I’m loaded, that wasn’t so ling was it?— oh wait, gotta load my data… Theeeere you go I’m loaded! No wait, that thing as well…”
But then again I tend to avoid frameworks and thing software developers shouldn't pick completely inefficent patterns even if it is very convenient for them.
In 2017, Saudi Arabia has given citizenship to the social humanoid robot Sophia. She became the first-ever robot to get citizenship of any country in the world.
Hmmm, not sure this is the best approach. There is no reason to deceive your user.
> Hot tip: Use an ease-in animation to make the progress seem like it’s accelerating.
So annoying when websites try to deceive me with a quantified progress bar inversely inching towards completion even though I cut off Internet five minutes ago.
Progress bars for I/O are typically easy. Progress bars for computations with deep call graphs are typically more difficult.
It's a challenging problem, because either attempts at a solution (being direct, or being indirect) causes a worse user experience due to expectations of linear progress. For example proposed solution 1 in the article would have you create some sort of animation or additional progress bar to let people know if something is actually stalled/dropped vs something just taking more time, you would still be lying to them, but it's for the benefit of user experience.
But the moment it's "wrong" it's annoying.
No. Just no.
Edit: Humans make mistakes, give them a little time for introspection before something non-reversible happens. Also, for people like you, there's usually an option for "don't show this again".
Pretending to be busy for five seconds with no way to undo it or cancel the request while waiting won't save you your marriage.
I know of a case where a delay was introduced because users didn’t believe the task was done because it happened so quickly, and contacted support thinking there was a problem (there wasn’t).
All related support contacts stopped after the artificial delay was introduced.
As you may have guessed, these were not technically savvy users. But it’s what they needed.
But on a more constructive note, perhaps instead of introducing artificial delays, you could instead show the user proof that the action has been completed?
It is hard because the blocking operation may be very deep in the call stack, and each element must collaborate. Not all APIs support asynchronous progress events. Proper progress bars are abstraction breakers. For example, your API may abstract away the fact you are on a network or doing things locally, except that if you want progress, these are very different cases, so you want to know the underlying situation. Ideally you should also know how good your connection is: an overcrowded airport Wi-Fi doesn't act the same as wired LAN.
UI/UX people can only do with what their back-end provides. The back-end can only do with what the APIs they use provide. The APIs can only do with what the system provides. So sometimes, a spinner is the only thing that can be done within a reasonable budget.
If not, then maybe just don't include it at all... I hate it when websites or apps do stuff spontaneously.