[HN Gopher] LoaderShip - CSS-Only Loaders
       ___________________________________________________________________
        
       LoaderShip - CSS-Only Loaders
        
       Author : marban
       Score  : 178 points
       Date   : 2024-01-19 06:34 UTC (16 hours ago)
        
 (HTM) web link (www.loadership.com)
 (TXT) w3m dump (www.loadership.com)
        
       | tmikaeld wrote:
       | This is great, it even has a configurator:
       | 
       | https://www.loadership.com/loaders/dot_circular_scale
       | 
       | Thanks for sharing!
        
       | TekMol wrote:
       | 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?
        
         | mcny wrote:
         | 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
        
           | kevincox wrote:
           | Yeah, lack of error notification in general is a huge problem
           | with many UIs.
           | 
           | It is worse than the other common problem of showing "no
           | results" until the actual results load in.
        
           | teh_klev wrote:
           | > Often in aspdotnet we have programmers
           | 
           | Pretty sure this is a problem across many other development
           | platforms. Odd that you singled out aspdotnet programmers.
        
             | mcny wrote:
             | > Odd that you singled out aspdotnet programmers.
             | 
             | I was talking about myself but didn't want to admit I am
             | the problem. (:
        
         | jefozabuss wrote:
         | 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.
        
         | kasbah wrote:
         | "Reticulating splines"
        
         | dspillett wrote:
         | _> 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?).
        
         | duxup wrote:
         | At least as far as the web goes:
         | 
         | 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?
        
       | csiegert wrote:
       | The activity indicators look nice and the configurator is great!
       | Bookmarked.
        
       | fayazara wrote:
       | Looking good, I've been using these recently -
       | https://github.com/n3r4zzurr0/svg-spinners
       | 
       | Will give these a try for my next project
        
         | asimpletune wrote:
         | I think that's the first time I've seen SMIL outside of an SVG
         | spec
        
       | nullzzz wrote:
       | Looks great. Who's behind this tho? Could not find anything on
       | the authors.
        
         | csiegert wrote:
         | The About page (link top right) says "Loadership is a side
         | project of Jingcheng Chen" and links to https://chen.works/
        
       | RileyJames wrote:
       | 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).
        
         | kevincox wrote:
         | 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.
        
       | Rygian wrote:
       | There is some irony to the fact that this page does not even show
       | a loader icon if javascript is disabled.
        
       | richrichardsson wrote:
       | To the authors: Block Grid Scale with a block gap is outside the
       | frame (upwards and left) by the gap amount.
        
       | lwhi wrote:
       | Should we even bother with loaders? .. how can we load assets and
       | carry out transactions that have async behaviour in another way?
       | 
       | Maybe load in the background or show some other content while a
       | long operation is taking place?
        
       | eole666 wrote:
       | 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.
        
       | elaus wrote:
       | 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.
        
         | 9dev wrote:
         | And it's so easy:                   loading = true         try
         | {            await fetch(...)         } finally {
         | loading = false         }
         | 
         | ...while the error bubbles up to some global handler. This is
         | such a low hanging fruit for the user experience...
        
           | JoeyJoJoJr wrote:
           | To be fair, it usually starts out that easy, until you
           | require multiple fetch requests and conditional logic for
           | separate CRUD operations.
        
             | internetter wrote:
             | I've worked in codebases where this bubbling is trivial,
             | and ones where its impossible. The key is abstractions.
        
       | JimDabell wrote:
       | 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.
        
       | unkoman wrote:
       | I would love to see old load-bars instead as well.
        
       | rgmerk wrote:
       | Heh. I saw "loader" and was expecting a reimplementation of the
       | Ocean Loader:
       | 
       | https://youtu.be/njTxV8blffc?si=HxTbACcLCZYDmvig
        
       | arnorhs wrote:
       | 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.
        
         | nkrisc wrote:
         | 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.
        
       | internetter wrote:
       | 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!
        
       | Uptrenda wrote:
       | It would be more useful if you could show progress %.
        
       | billnreed wrote:
       | 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
        
         | yoavm wrote:
         | these are really great, thanks for sharing! love the
         | simplicity.
        
       | YoshiRulz wrote:
       | The only good spinner (and don't forget to include something for
       | screen readers[1]):                 <progress></progress>
       | 
       | 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...
        
         | duxup wrote:
         | Except it looks like a progress bar that isn't actually
         | indicating progress ... that seems off to me.
        
           | deathanatos wrote:
           | 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.)
        
             | duxup wrote:
             | 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?
        
         | eddd-ddde wrote:
         | What about aria-busy? I love how picocss approaches spinners.
        
         | electroly wrote:
         | > 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
         | <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.
        
           | deathanatos wrote:
           | Same on macOS ... and wow is it animating at a really low
           | frame rate.
        
       | eddd-ddde wrote:
       | 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.
        
         | gregmac wrote:
         | 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.
        
           | tomxor wrote:
           | 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.
        
       | peyloride wrote:
       | Looks very cool, thanks for sharing!
        
       | smaudet wrote:
       | Issue I noted:
       | 
       | 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...
        
       | madrox wrote:
       | 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.
       | 
       | These days, cutting edge loading UX means placeholders:
       | https://uxdesign.cc/stop-using-a-loading-spinner-theres-some...
        
       | redder23 wrote:
       | 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.
        
       | atjoslin wrote:
       | <3 <3 <3 <3 THANK YOU
        
       | pmdr wrote:
       | 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.
        
       | Rucadi wrote:
       | This is genius, thanks.
        
       ___________________________________________________________________
       (page generated 2024-01-19 23:01 UTC)