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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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-*.
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 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.
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
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.
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.
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 :)