Progress Button Styles | Hacker News Reader

Progress Button Styles

tympanus.net

287 pointsmadisonmay52 comments

Is there a GitHub repo for this, or a version control link of some kind? The page doesn't appear to offer any way to get the code short of yanking it from source (which seems less than ideal because the page doesn't clarify a license), and the blog post linked in the top right only offers a zip.

</rant>

I do realize that not everybody subscribes to the "Everything is a repo" philosophy that holds sway for me, and that tarballs and the like are still used by a significant portion of the internet to share code. I just wish I could sell more people on The Repo Way :)

http://tympanus.net/codrops/licensing/

That's not really a license and more of a tl;dr. There's a lot of value in picking an existing license to ensure people know what's up, and also that it can hold up legally if you need it to.

EDIT: To clarify, yes, I know that putting it there makes it "their license", and if I were to use code from their site I would adhere to it. My concern is that, because it's not actively shown when viewing the code itself, and because it's a roll_your_own license, it impacts how comfortable I'd feel taking the code and using it as part of other projects.

Yeah. I won't touch these because of that license.

It's essentially CC-SA, but with this: "You are not allowed to take our work “as-is” and sell it, redistribute or re-publish it, or sell simple “pluginized” versions of it."

NOPE. mit/bsd/isc/lgpl/apl or compatible or bust.

https://github.com/codrops/ProgressButtonStyles

<3 Thanks!

This reminds me of this UX Overflow post about the right way to do "Yes, delete it": http://ux.stackexchange.com/questions/49991/should-yes-delet...

I think a more contrasting approach to color is likely better - maybe you start with a green button, which goes Gray on click, and then fills with brighter green. This will avoid issues with color-blindness, or even just myopia, where people won't really see the subtle color filling in.

I really love this effect. In use, I would suggest changing the text from "Submit" to "Saving", to better explain what's happening.

My first thought was to throw on a loading spinner, but changing the text sounds like a much better idea :)

> changing the text from "Submit" to "Saving", to better explain what's happening

I took a similar idea from a small remark in the recent "what I would do if I were Tarsnap" article. It made me wonder who uses the verb "submit" nowadays, what meaning does it have to users that are not web-developers (and immediately think of `<input type="submit">`)?

Arguably it makes sense because you are submitting a form to web server, but what common user really thinks of this action in that way?

Maybe this is super obvious to some people, but I was reminded that you can put pretty much any verb in context there, and it'll probably be better than "submit".

This looks great, nice work.

Do people using this sort of thing (or the YouTube style top of the page loading bar) actually get back real % completed values from the server or do they just use it to show that _something_ is happening?

I think the vast majority of sites just make the progress bar move in a way such that it appears to be loading quickly/making progress, but when the server is finally ready the bar just jumps to the end.

Internet Explorer on Windows Mobile does this too. If your connection drops out, the progress bar continues to move towards 90%, then gets stuck there forever. It's maddening.

That being said, giving a good estimation of page load time is downright impossible.

You don't know in advance how many resources you need to load, you don't know in advance how large they'll be, or how long the DNS reply will take ...

If you don't want the scrollbar to move backwards, you can just give a rough approximation of progress, if any. And if you just wait until you certainly know how long it's going to be you're probably almost finished anyway.

I guess there's a reason web browsers nowadays just use a little spinner that says »I'm doing ... uhm ... something!« instead of them pretending »I'm 46.5 % done«.

You can't do this very accurately, sure, but you can add some meaning - e.g. report back when each of a number of known steps is completed. That gives a vague idea of whether we're talking seconds or minutes. I might be able to do something else once I know a specific step is complete.

The obvious exception would be file uploading, which can and should have a true progress indication.

I built an importer script once -- the importing itself was handled in a worker, so when the file was first submitted, the importing would be done on a separate thread in a Transaction -- pretty much making it impossible to actually track progress. I set it so that it would 'tick' up a couple % every Math.rand(0..2) seconds; but also poll for the statuses I did know about (accepted, queued, started, finished).

It honestly made for a very comfortable UX -- customers did not know it was not actually representative of the true status, but they were nevertheless okay with waiting the 30~ seconds it took.

Very nice.

I mean this as a total compliment: HTML/CSS/JS seems to be quickly catching up to the opening scenes of my two favourite news shows from the 1990s: The Day Today [1] and Brass Eye [2]. Thirty second clips of those scenes for each below:

[1] http://www.youtube.com/watch?v=s_nk8PzL0Zw [2] http://www.youtube.com/watch?v=OuCAQnWyAiQ

I like the top-line horizontal version. It's consistent with the new "progress bar on top of single-page application" convention.

The folks at Tympanus have thoughtfully included a tutorial for these effects as well. Check it out at http://tympanus.net/codrops/2013/12/12/progress-button-style....

Some might argue that buttons should remain buttons and loaders should remain loaders.

After thinking about it for a minute, I don't have an opinion on your comment either way, but I think it's a good question to ask.

This control is more concise than two controls, which is nice especially on mobile. But, we could easily hide the button with animation, and replace it with a classic loader. Can we say anything about which approach is better, without empirical data?

I excitedly up-voted the post after clicking a few buttons, and I think the author is a creative and clever person either way!

Once the user clicks "Submit" you have to disable the button to avoid double submission, so might as well replace with a progress indicator.

I highly recommend all of tympanus/codedrops articles and examples. http://tympanus.net/codrops/category/playground/

The site has an amazing collection of UI experiments and tutorials! Love it!

This page is too green. Can you try with a white background?

I don't mind the green, but trying to read green on green is a bit hard.

You can try it yourself, just open firebug/Chrome Developer Tools and edit the body CSS. Don't rely on others to do for you what you can just as easily do yourself.

Mhmm, it took a few seconds for my eyes to re-adjust once I came back to HN. I wonder if there's a threshold for color balance where it starts to noticeably alter your perception of other colors?

If this sort of thing interests you then I'd recommend following the Codrops blog. They are always coming up with very innovative and interesting stuff.

Viewing on Chromium, and I can't see a single difference in the 10 styles that have "perspective" in the name. Am I just being dense?

It says at the top "Without support for transform-style: preserve-3d you will see the fallback style (fill horizontal)." I think support for it is a little flaky on certain linux/graphics driver combos.

Neat. It would be even nicer if it had hover and active states for the buttons as well.

I love the whimsy present in some of these, especially in `flip-open perspective`.

I'd def go for ROTATE-SIDE-DOWN PERSPECTIVE. Clear, concise and intuitive.

This is exactly what i was looking for a long time.

Super.

I would like to see a version where the progress bar fill-color gets brighter colors as it nears completion.

ROTATE-ANGLE-LEFT PERSPECTIVE FTW

I hear you. I never saw this before, and it's rare to see a new concept in UI for the very first time. So that one had me slightly excited, too :)

Though I generally dislike loading bars for images (I prefer progressive jpeg), some sites do insist on using them, and I think this particular effect could look fantastic for thumbnails. And enhanced to use two colors, it could also be used to indicate buffering status and seek position when playing short audio samples (a gallery of birds and their song is the first thing that comes to mind haha)

Why have a progress bar at all? I'd rather "Submit" and... things happen immediately.

I do realise that there's probably some server-side things going on when you've submitted, but you could do that at the very last form input, and once the button is pressed, magic appears. No loading, no progress bars.

If javascript is disabled, these buttons do not work. Always need a fallback plan.

I know this is a WIP, and it's awesome. Very green though. ;-)

Explain yourself why we "always need a fallback plan" if JS is disabled.

Without saying "screen readers", as they're 90%+ JS enabled these days.

Because millions of people use Opera Mini 4.x which does not support most JavaScript functions.

Millions of people are not using Opera Mini 4.x on any sites I actually work on. They constitute a small fraction of a percent of total visitors. The opportunity cost of developing fallbacks for them is simply too high when we could be developing additional improvements for the vast majority of our userbase.

Additional improvements, or bling? That's kind of the point, breaking functionality for mere shinyness is silly. If you need javascript anyway, that's different of course.

We're talking about a submit button here.

You're claiming, millions are filling in long web forms with their feature phone numpad keys?

Give me a break.

So that the site still functions if JS is disabled or unavailable, which can happen for many reasons including network policy, browser support, personal preference, availability (especially if you're hosting the JS on a separate server), or bugs in the source. Explain why you would choose NOT to implement a fallback plan, given that 99%+ of the time it is trivial to do so.

If half my resources aren't loading, or aren't loading in full, despite all the fallbacks built into HTTP itself to avoid precisely that scenario, there's no fallback on Earth that can work around this.

If my JS would load in half, my no-JS form might also load in half, what do we do now. Have a fallback where we accept the form in pieces?

As for people who have a "personal preference", well, they might as well have a personal preference to browse the web via telnet. It's their problem.

The requirement to use a full, working web browser to browse a web page is hardly extreme.

Let's say your JS is hosted on a different domain from your html (quite a common scenario) and that domain can't be reached (for any of the many possible reasons). Or a bug is introduced into the javascript (which happens a lot). In each case, your approach results in a broken page, whilst a fallback approach still works perfectly.

Re: personal preference - have you never heard the saying 'the customer is always right'? No business in its right mind would purposefully turn down money from a bunch of its customers just because they happen to have a personal preference which can easily be accommodated.

Note that a web browser without javascript support doesn't fail to be a 'working browser' just because you say so.

Note that I am not saying you must do this on your personal blog, or that Javascript isn't a very useful feature of today's modern browsers. Just that it's good engineering practice to be inclusive and to handle exceptions gracefully.

I don't do this for when JS is disabled; I do this because networks are unreliable, especially cellular ones. JS on websites is growing in number of files and in number of bytes. If your JS is at the bottom of the page and has to download and execute before the page is usable, users on cellular networks in particular can be looking at an unusable page for a significant number of seconds.

They do work with js disabled! If you have a form, a button without a type will trigger the submission of that form. The demo does not include a form because is just showcasing the different possibilities for these buttons.

Sorry I disagree, javascript is here to stay and it's safe to say near everybody has javascript enabled. Those who don't make a concious decision to break their experience on almost every modern site.

And as always, measure your audience. Why waste time and money for the 0.01% of users without js?

Reply on news.ycombinator.com