Buttons with built-in loading indicators | Hacker News Reader

Buttons with built-in loading indicators

lab.hakim.se

409 pointsSpiritus61 comments

This is very pretty, but there's no need for a larger, separate JS file. All of this can be handled with CSS and a simple JS command that adds/removes a CSS class on click.

Quick demo: http://codepen.io/ultimatedelman/pen/klDHy

Since you wouldn't obviously use all the effects in this article, just pick the one you would use and have the .loading class effect the correct change.

UPDATE: now with fewer elements. Only HTML element needed to achieve this effect is the button itself :)

The other nice touch in Ladda is that it disables the form button on activation. Again, given your demo, not hard to replicate with a `this.disabled=true` statement.

You can also do this with CSS:

pointer-events: none;

cursor: not-allowed;

Though doesn't stop giving it focus and pressing it with the keyboard.

Yeah, been doing it that way for the signup form on Webpop for a while now (albeit with a different animation).

It's not known very well, but Bootstrap has similar functionality, albeit not as pretty:

http://twitter.github.io/bootstrap/javascript.html#buttons

That's actually the technique I use for buttons in my apps, and I believe I prompted them to add it to Bootstrap. You can see the thread about it here where it was added: https://github.com/twitter/bootstrap/issues/471#issuecomment...

But my point isn't who-invented-it, it's that it's very easy to implement this in your own buttons without using Bootstrap. I still use my own implementation, despite suggesting it to them. Just create some data attributes (I have data-default-message, data-inflight-message, and data-success-message) and change your buttons appropriately. I have a standard function that I call on my forms that handles that for me, which I've gisted here: https://gist.github.com/pamelafox/5714109 You could do that in a more elegant way than that bit of code. :-)

I prefer the changing-message approach to the showing-the-indicator approach because the verb stays, and you remember what it was that you were doing. Handy for us forgetful folks. You can use both, too, of course.

It's a great technique for buttons, even without the nice design. I've wondered for years why this is not more common. Having a "submit" button change state is such better UI than those horrid messages warning you not to click twice—I still run into that from time to time.

The best route would probably be to show that warning somewhere, but hide it using JS. That way it's visible in scenarios where JS isn't available.

I combined the bootstrap method with some Font-Awesome, and accomplished getting some animation in my buttons in a simple manner.

See "Buttons" section at http://fortawesome.github.io/Font-Awesome/examples/

Font-Awesome also has a really nice 'Animated Spinner' icon as well on that example page, which works nicely with Bootstrap buttons.

As long as te app won't "break" by the user navigating away, anything that avoids the "loading" modal is a great UX improvement. Ajax errors can also be sent to the button with "error" icon, BTW.

agreed, might be trivial but i think the button text could as well switch to 'Submitting' like bootstrap

Did not know about this at all, thanks

Hakim has more amazing experiments on his site (incl. Sinuous) worth checking out: http://lab.hakim.se.

Wow, he's talented. Avgrund seems like it could get some use on a project i'm working on now: http://lab.hakim.se/avgrund/

I love http://hakim.se/experiments/html5/keylight/03/

All of those are useful.

Hm, I was going to say it is slightly messed up in Opera -- the boxes don't move like they should -- but I guess it's not going to matter in the very near future. :(

What impresses me the most is the JS. It is so clean, concise, and, the only other word that I can think of, professional. It puts the onus of capability on the browser and doesn't try to make up for those who lack. Sure you can shim addEventListener or setAttribut, but F IE (really), it has been adding complexity for far too long.

Thanks for pointing this out. Based on your comment I reviewed and the style is really nice. I haven't seen that method of returning the public API before but like you said, it is very clean.

Nifty. I don't know how we missed the possibility - this looks really nice.

Oh, and thank you for adding a license. So often I see neat hacks posted, without any license at all...

This is quite nice. All of the animations would be made better by removing the bounce at the end; it's a jarring way to end something that's otherwise very smooth.

Nice! Although the loading gif looks a bit dodgy on retina screen. I'd suggest playing with CSS and making that loading bit a pure css shape.

We did something similar on one of our office hack days.

http://waitable.adstruc.com/

https://github.com/ADstruc/waitable

We built a generic jQuery plugin which binds to jQuery promises, taking care of the waiting state and double-submit issues while firing off Ajax requests.

I like your implementation. The demos in TFA all seem like pretty bad UX to me.

On Firefox, a dotted line appears around the button's text when it has focus (after click for instance). IMO, it ruins the nice clear style of the buttons.

You can remove it with the non-standard `button::-moz-focus-inner{border:0}`. Then you could define some style for `button:focus{...}` to help keyboard navigation.

Or just button:focus{ outline:none; }. That should remove focus styling on all browsers, last I checked.

Not on Firefox. It doesn't use the pseudo-class :focus{outline} for buttons' dotted line, but the pseudo-element ::-moz-focus-inner on which a border is applied.

Note that the dotted line appears inside the button, around the text, and not around the button like :focus{outline} would do.

This is really cool! The only thing that makes it a little ugly for me is that when I click on it, my browser puts an ugly grey box around the text like I'm selecting it. Could this be solved by immediately changing the focus of the input?

That's easily solved with CSS.

You wouldn't want to remove the styling completely, but definitely get rid of the browser default and use a custom focus style that looks better.

please don't mess with focus that way, it ruins accessibility.

These buttons become unclickable once clicked upon. There is no additional loss of accessibility if you remove focus at this point, on the contrary.

the unclickability is also an accessibility issue imo. I know which problem it solves, but creates another when the site becomes unresponsive due to connection loss etc.

This is usually handled by returning the button to its normal state after an error or normal response. With ajax forms you have to catch more errors so if it isn't done it's just because the developer didn't take the time to set it up properly.

I agree with you on that. The primary usage mode for these buttons are probably AJAX forms, and those can be very frustrating for lots of reasons. I think it's great to have some kind of visual feedback that you're action is being performed, but at the same time transmissions errors should not result in a stuck app. That's why I think the UI practice suggested by these buttons is likely to result in user frustration, but still there is no additional usability loss when removing the focus from an already disabled button.

Genuinely interested: how would it be more usable if the buttons remained clickable after they'd been clicked? If you lost your connection, wouldn't you expect some kind of error? In that case how would it be more usable to be able to click the button again?

if I lose connection and the form is unresponsive I have to f5. often forms have some custom js selectors and after refresh some elements (or even whole formsets) lose their data.

of course an error would be nice, but the main goal is to submit the form I spent the last minutes filling in.

Good point, thanks for the reply.

It's worth a note that these buttons are very laggy in MobileSafari, except for zoom-in and zoom-out, which use -webkit-transform and thus have hardware accelerated animation. While slide-* could be changed to use -webkit-transform, I'm somewhat surprised that the performance of the others is so bad, and I wonder if there's some not-completely-awful trick that would improve expand-*.

I actually was impressed by their smoothness on my 4S. What device are you using?

They were a little choppy on my iPad mini.

That looks cool. But in most of my projects, I use a "frame" structure. After submitting something, the frame changes to either left or right, completely moving the submit button out of sight. So while this is very cool, it doesn't work for popups and frame like designs which are supposed to "move" immediately and process ajax requests in background to give an illusion of speed.

I actually did a similar thing for iOS, I'll try to extract it from that project and open source it when I find time :)

This is also a nice solution

http://fgnass.github.io/spin.js/

This seems to use it

I saw this and just thought, "why isn't this the way we do buttons and loading" nice

A few years ago I built a button for an iPhone app that turned into a progress bar while loading:

Here's a CSS version of it (with image assets).

http://codepen.io/kballenegger/pen/uJGCF

I like the slid.es examples. Are there some JavaScript based slides, which work on a server so that one user can navigate to new slides and the other users see the change in their browser?

Nice. I like the in-place-with-overlay option particularly, though I can still interact with the other buttons while the overlay is in place which I was not expecting.

I dug into that, and what I found blew my mind.

Usually these lightbox/modal overlays use an extra div either loaded with the page or injected on the fly that covers the entire window and is positioned just below the modal on the z-axis (z-index).

His solution was to give the button a really massive box-shadow :O

    box-shadow: 0px 0px 0px 3000px rgba(0,0,0,0.8);

I'd never have thought of that.

     ---
    |   |   <--- the box
     ---
    
      X     <--- where Hakim thinks

Agreed, a nice library overall.

And at first I was impressed by the overlay, especially considering the novel implementation. However, after a little thought and setting that novelty aside, I think that effect is broken. It's simply not at all conventional for a fully masked page to retain interactivity (despite the odd site that allows this).

Worst case scenario, an unsuspecting user activates an overlay button, and while it's loading, starts clicking state-changing buttons around the page just to kill time.

Something like this, but with a progress bar instead of a generic loading thing, would also be very nice.

this can be very difficult, as very often the front end is not aware of the loading status of an item. pretty much only files being uploaded can have any sort of progress attached to them.

Interesting use case, but not practical enough. All the times when you need to show a loading indicator do not occur after clicking on a button, loading indicator needs to come up when any amount of delay is anticipated. It can show up after clicking a link, image etc etc whereas this example implies as if loading indicator is only need when a button is clicked.

I expect this is trying to solve problems like double form submission.

very neat, and incidentally made me discover slid.es, what an extremely well made app that is.

Same here, slid.es is brilliant!

I had to learn more before I throw out PowerPoint, so I Googled (which is difficult because of the top level domain in the name, had to search with quotations). http://ltlatnd.wordpress.com/2013/05/20/slid-es-for-lightwei...

TLDNR: Formerly Rvl.io, free tier, commenting. Paid tier at $7/mo has revision history, private slides and offline export.