41–50 of 65 posts
I couldn't make the square go from bottom to top, or right to left, only top down or left to right:
https://www.loadership.com/loaders/block_grid_scale
270 degrees or 180 should achieve this effect but seem to be aliased instead...
These days, cutting edge loading UX means placeholders: https://uxdesign.cc/stop-using-a-loading-spinner-theres-some...
The only good spinner (and don't forget to include something for screen readers[1]): Works in every browser, and out-of-the-box is visually consistent with the rest of the system. [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pr...
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 . 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.
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 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?
The only good spinner (and don't forget to include something for screen readers[1]): Works in every browser, and out-of-the-box is visually consistent with the rest of the system. [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pr...
> visually consistent 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 . 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 sur…
The only good spinner (and don't forget to include something for screen readers[1]): Works in every browser, and out-of-the-box is visually consistent with the rest of the system. [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pr...
Except it looks like a progress bar that isn't actually indicating progress ... that seems off to me.
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.)
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 unrelate…
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.