Lately my internet connection has been ridiculously bad. It made me realise how often UX is ignored for bad connections.
One of the things I notice with SPAs is that since the browser navigation does not occur normally, I get no indication from my browser that a link is loading, so the app is completely responsible of adding their own navigation indicators (which is uncommon to see in the wild).
Also sort of unrelated, I constantly see search forms that are "real time" but do not even abort previous requests, so to me it appears as no feed back, then once I finish typing I get a new set of results every second or so until it completes, making it extremely frustrating.
So much of this is because developers work on high-end systems with a ridiculously fast internet connection (whether at home or work).
It isn't super-hard to fix this, but does take effort/time/money. For example, test on slow devices on slow connections. There are proxies that can throttle and introduce latency, or even let random connections timeout.
There's a catch-22 here though: doing this early in a product's life probably doesn't make sense as it's almost certainly better to focus your efforts on creating the product. But the longer you wait, the harder (== more time-consuming == more expensive) it is -- there's more architecture to change, there's complex page logic that eg didn't account for potential timeouts while doing a callback to validate something entered in a text box is unique, etc.
There really is very little excuse for it, throttling is built right into the dev tools of both Chromium and Firefox, it's a couple of clicks away. It's as important as cross browser testing and easier to do.
Another thing I've noticed a lot of sites are very poorly optimised for is latency. HTTP 1.1 is already poor in this regard due to the number of round trips required for setup, and when you start chaining these together latency becomes highly magnified, especially if they aren't on the same domain and you need a whole new HTTP setup for each step in the chain. Even with HTTP 1.1 this can be minimised by looking at the chain of requests and reorganising them to be less dependent on each other.
When your latency is in the single digits and it get's multiplied by 10, that's at most 100ms, now go to mobile and it's 400ms, now in the worst case a low bandwidth connection like ADSL (which will affect latency when the weight of each request is high) or a distant connection on a different continent and you can easily get into 10s of seconds.
I find this one the most annoying because the fundamental problem is poor utilisation of the connection, they don't even need to change the size of the payload, there are simply long periods when the browser is waiting to find out what to do next and the connection is mostly idle.
There's the "Network Information API" but so far its a Chrom* only thing https://caniuse.com/netinfo and I can easily see how it might be a privacy concern given that it gives yet another data point to everyone
Not specific to the submission, but I've basically lost all trust in loading spinners.
Too many websites keep showing the loading animation indefinitely if anything unexpected fails (invalid response from backend, broken connection, …).
It's not even a problem with the concept itself (binary is/isn't loading), it's just bad implementations that have ruined it for me subconsciously.
I've been frequently fascinated by is loading screen UX. How we choose to present loading can have a huge impact on how a customer views a product. For example, if you have a bespoke loading icon, users will tend to think the issue with with your product and not the underlying system. If you use a default system loading icon, they'll blame their phone/OS/wifi.
I wish loaders would provide some feedback on what is going on.
So often, I look at a loader and think "How long will it take? Is it actually still doing something? Or should I try to reload the page?".
Also, I often wonder why developers put tools like this on an extra domain instead of just putting it on a page or subdomain on their personal domain. Is there a reason for this that I am missing?
> I wish loaders would provide some feedback on what is going on.
Often there isn't much feedback that it is easy for the client-side to give, it doesn't get any feedback until the first byte arrives in response and the time between request and first byte is far more significant than the rest of the transfer.
For things like file uploads/downloads proper progress is very useful and it is irritating when that isn't present (uploading photos to facebook on a slow connection for one example). Client-side things like number crunching too.
One problem you see sometimes where things can be easily monitored and the user informed, is that developers neglect to test in less than ideal conditions. The process works within a second on their devices and connections so they don't think to include a progress indicator, it is only when someone tried the result on something slower (an old slow CPU over a patchy mobile connection) that this becomes apparent. Also more detailed progress information is on the “nice to have” list so gets passed over in favour of bug fixes and other feature updates.
> I often wonder why developers put tools like this on an extra domain instead of
I think just fashion/appearances. It may also be an SEO thing (short URLs doing better there?).
1. It gets worse. Often in aspdotnet we have programmers who will only remove loader on success so you could get a 500 internal server error response and the loader never goes away.
2. I think it makes it easier to get to your website without having to use search and it is easy to share like are we web yet dot org
I agree generally but things like "How long should it take?" is more about your internet speeds / consistency, or very odd unforeseen issues on the back end, and frankly there's no amount of goofing around with even more code on your computer to determine local internet issues ... will tell me any number that makes sense.
The only time calculating "how long" is under ideal circumstances (and at that point nobody cares) or say very predictable large back end workloads. As soon as things get variable, I can't give you a reasonable number.
Sorry if that is a bit of a jumble of words and ideas there, I'm actually taking a break from troubleshooting this exact kind of issue. Customer has varying weird internet issues, wants to know "how long" ... bro wat?
Sometimes I see additional messages pop up next to loaders after certain times passed.
Personally if I load from multiple endpoints at the same time I usually add a ##% in the middle of my loading circle calculated based on total and ongoing requests.
In Chrome on Windows it shows a back-and-forth bouncing progressbar that is not at all similar to the system's indeterminate progress bar styling. I've never seen this used elsewhere, other than here in this Chromium implementation of <progress>. It's (mostly*) not objectionable but it definitely doesn't blend in.
* Suffers from a newbie trap: if you're going to bounce back and forth, you need to make sure there's a frame where the bouncer is all the way at the end of the control before the direction switches. This implementation doesn't, so sometimes the moment when it hits the edge of the progressbar happens between frames, so you miss the actual bump which looks disconcerting.
Most UI toolkits I've used have a notion of an "indefinite" progress bar. In the past these have sometimes done like a horizontal barber pole animation. In fact, I have memories of the one in Thunderbird doing this; it would be a normal progress bar while the email's data was sent, and transition to an indefinite bar while it awaited the server's response. After all … there's no "max" or "value" to the progress … we're just waiting for a singular response.
Windows, in the glassy Vista era, had a green one that would shimmer & slide a small faded green blob (for lack of a better word) across the bar.
(IMO better than what Explorer did for years, which was to show a definite progress bar, i.e., one with a shaded portion indicating some % completion … and then just lie about it. It would just fill the bar up with an exponential decay towards 100%, but never actually get there … and was really just an animation.)
I agree that it is a common pattern. I just find it off.
Also awkward to use as a horizontal bar to show progress has to be somewhat wide, usually way wider than a spinner.
The lying thing is an issue, but I don't see much difference between a bar lying and a bar that ... by design is not a progress bar / not telling the truth?
I did assume this was a webpack or otherwise package for loading css libraries. Took me a while to work out what it actually was.
Probably because I’ve had such headaches with webpack within rails and would love something to make it disappear (yes I know there are newer solutions but each one breaks things in new and unique ways).
Yeah. I also had to get down past all of their points before I saw the images to understand what this is. And one of the points ironically said that it didn't waste my time.
I've never heard the term "loader" being used here. Since a loader would be something that loads. These don't load anything, they just indicate that loading us happening. I typically call these "spinners" or sometimes "throbers" as that is what they do.
I would strongly recommend write "loading spinners" into one of the first sentences on the page.
I feel like skeletons are much better than loaders. I never used them until recently (I have had the displeasure of using an API that takes 700ms+ per request for critical pathways) and the change was jarring until I used skeletons, now it feels 2x faster!
Agree with some of the other commentors that I don't associate "loader" with progress indicators / spinners. The preferred term for these in my book is "loading indicator"
A lot of these terms are overloaded already. Android made it esp. bad by using "spinner" for a dropdown box, and then they used progress indicator for things that normally you'd use "spinner" for.
Ultimately a "spinner" isn't really a good term since not all loading indicators spin.
I might remember seeing the term "loader" in the jQuery days, but I haven't seen it used that way for a while.
GUI components called spinners were called so because they originally resembled physical controls which had options printed on a barrel, which was then mounted below the dashboard surface with a slot to reveal the current selection, and had a ridged wheel exposed so you could spin it. Most GUIs now show you all options at once because they can and it’s better.
Now if only there were a website for 'Oops', 'Something went wrong', 'Uh oh' and similar messages instead for (God forbid) actual informative error messages.
This just ends up putting a stack of empty divs into your page. Use SVG instead of trying to abuse HTML to draw things. SVG is literally designed for this, you should use the right tool for the job.
The big "Get started" button does nothing (or maybe show a modal and close it really quickly). This is a good way to scare users away.
The loaders are nice thought.
The linear dot wave is a great example to show the difference between linear and cubic bezier. Its basically ruins the hole thing if you use linear animation.
Think of an app doing an AJAX call to load something from a database:
1. App sends HTTP request
2. Load balancer gets request, sends it to actual server (or lambda or whatever)
3. Server gets request, makes database query
4. Database gets query, executes it against data
5. Data is returned to server
6. Server returns to load balancer
7. Load balancer returns data to client
Every single one of those points is a potential delay, and a potential failure point, and unpredictable. You don't know if the servers are heavily loaded or not, or if something is containerized and doing a cold start. You don't know if your query is going to return 1KB or 1GB of data.
It's not that it isn't possible to do something better than a spinner, but it's a really hard problem to predict "done". In most cases -- for example if your 95th percentile response time is <200ms -- the cost to do it doesn't justify the effort.
One of the things I notice with SPAs is that since the browser navigation does not occur normally, I get no indication from my browser that a link is loading, so the app is completely responsible of adding their own navigation indicators (which is uncommon to see in the wild).
Also sort of unrelated, I constantly see search forms that are "real time" but do not even abort previous requests, so to me it appears as no feed back, then once I finish typing I get a new set of results every second or so until it completes, making it extremely frustrating.