Live data from Hacker News

LoaderShip – CSS-Only Loaders

loadership.com

51–60 of 65 posts

Re: LoaderShip – CSS-Only Loaders

#51
post #36

Earlier quoted context omitted.

Except it looks like a progress bar that isn't actually indicating progress ... that seems off to me.

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'…

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?

Re: LoaderShip – CSS-Only Loaders

#53
post #49

[flagged]

Have those ever existed? https://xkcd.com/612/

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.

Re: LoaderShip – CSS-Only Loaders

#54
Glad we got the loaders sorted out.

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.

Re: LoaderShip – CSS-Only Loaders

#56
post #50

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…

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 l…

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.

Re: LoaderShip – CSS-Only Loaders

#58
post #4

Earlier quoted context omitted.

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

> Often in aspdotnet we have programmers Pretty sure this is a problem across many other development platforms. Odd that you singled out aspdotnet programmers.

> Odd that you singled out aspdotnet programmers.

I was talking about myself but didn't want to admit I am the problem. (:

Re: LoaderShip – CSS-Only Loaders

#59

I made a few CSS-only single `div` loaders a while back, it was a fun challenge to make them interesting while only using a single div. https://codepen.io/snowbillr/pen/QEagmW

these are really great, thanks for sharing! love the simplicity.

Re: LoaderShip – CSS-Only Loaders

#60

I made a few CSS-only single `div` loaders a while back, it was a fun challenge to make them interesting while only using a single div. https://codepen.io/snowbillr/pen/QEagmW

These are absolutely beautiful. I can't seem to find a license anywhere. Are they public domain?
Post reply on HN