Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NProgress: slim, site-wide progress bars

ricostacruz.com

Post reply on HN
Print view View original

61–70 of 143 posts

Re: NProgress: slim, site-wide progress bars

#61

Post by terabytest »

mistercow wrote: post #56

It's nice looking, but I'd like to see some actual user testing on whether this kind of progress bar performs its most important task. "What?" I hear you asking, "Of course it does! It shows how much longer you'll have to wait." In which case I must inform you that giving the user information is not the most important function of a progress bar. The most important function of a progress bar is Time Travel. That is to…

One point I'd raise about this is that I think it's fine to be able to indicate progress, be it just to keep the user looking at something while the page is loading, but I don't like how it seems to duplicate the function of the other progress indicators the browser has. Seeing the rise of client-side web apps, a browser API to show progress directly through the browser's chrome rather than custom UI patters would probably be great and prevent a lot of the fragmentation that things like this might cause. Plus, the less-savvy users might come to expect to see this bar everywhere just because they see it on YouTube, which I think is not a healthy thing for the web in general.

Re: NProgress: slim, site-wide progress bars

#62

Post by lzm »

rstacruz wrote: post #40
marbletiles wrote: post #38

This gives the pointer a blue beachball on Mac Safari. Is that intended? Have never been sure what the blue beachball's supposed to be.

Hi, I'm the author of NProgress. Yes! It's intentional. You can disable this by removing the `cursor: wait` rule in the CSS file.

That cursor makes me think that the browser has crashed/hung/is not responding.

Re: NProgress: slim, site-wide progress bars

#63

Post by mistercow »

bratsche wrote: post #46

It looks great, but why should we start promoting this as a UI pattern? This seems like a step in the wrong direction, and just because Youtube does it doesn't mean that others should too. If you need a visual cue that something is loading on your page, throw up some kind of spinner or other animation that doesn't have a fixed beginning and end. Unless you think you know how to accurately measure the time that http r…

Compare the subjective wait for the spinner and progress ar in this demo: http://jsfiddle.net/gUkgX/1/embedded/result/

Notice how much longer you seem to wait with the spinner? Watching a progress bar fill up with a definite end feels way faster. I have often used progress bars that have no connection whatsoever with the process they're "measuring".

Here's the technique I've found works well:

1. Estimate the time the operation will usually take. Call that W (it can be a constant, or you can use a heuristic to guess it specifically for the user).

2. Pick a function that asymptotically approaches 1, e.g. the error function. Transform it it so that f(0.75*W) = 0.75.

3. Now for elapsed time t, fill your progress bar to f(t).

The upshot is that the bar will start fast, and never completely fill. And for the first 75% of the estimated time, it will be accurate (as long as your estimate is). After that, it matters less, since it will take a while for the user's brain to adjust to the slower speed.

Re: NProgress: slim, site-wide progress bars

#65

Post by electic »

mistercow wrote: post #56

It's nice looking, but I'd like to see some actual user testing on whether this kind of progress bar performs its most important task. "What?" I hear you asking, "Of course it does! It shows how much longer you'll have to wait." In which case I must inform you that giving the user information is not the most important function of a progress bar. The most important function of a progress bar is Time Travel. That is to…

I think for me, it creates a unified experience for the user. Instead of coding up a slew of different spots for loading animations for different parts of the app, I can now have a loader on the top to indicate progress. It creates less code bloat for me and the user knows something is loading regardless of what action they took in the site. My two cents.

Re: NProgress: slim, site-wide progress bars

#66

Post by mcintyre1994 »

borlak wrote: post #36
benburleson wrote: post #7

Am I the only one that remembers SWF load-progress indicators and how retarded they were?

What do you mean? The SWF progress bars are one of the few that can actually be relied upon. A good example: http://armorgames.com/play/12141/kingdom-rush The Microsoft installation progress bars are the ones I remember as being ridiculous. Often going backwards, showing ridiculous install times, etc.

I think the worst was Windows movie maker, which used to seem to just randomly choose a time it might take and do a bad job of self correcting on the way. Oh, and of course there's a relevant xkcd, http://xkcd.com/612/

Re: NProgress: slim, site-wide progress bars

#67

Post by bratsche »

_greim_ wrote: post #50
bratsche wrote: post #46

It looks great, but why should we start promoting this as a UI pattern? This seems like a step in the wrong direction, and just because Youtube does it doesn't mean that others should too. If you need a visual cue that something is loading on your page, throw up some kind of spinner or other animation that doesn't have a fixed beginning and end. Unless you think you know how to accurately measure the time that http r…

There are at least some cases in modern client-side programming that you have access to progress information, and would therefore want a progress meter rather than a progress indicator . "Use spinners for everything" strikes me as short-sighted and reactionary advice.

You get a progress meter when you're pushing data, like uploading a file. And that makes perfect sense. Use a progress meter here, it makes sense.

This is totally different. It's explicitly saying that it might be used with pjax or turbolinks. I don't think there's a way to accurately determine progress information for one of these, the best you can do is use historical data and guess. In this case I think using a progress meter is a bad pattern.

Re: NProgress: slim, site-wide progress bars

#68

Post by gedrap »

Trufa wrote: post #47

A lot of negativity here, I find this quite beautiful and useful for some cases where the UI allows it.

Well, a wide adoption of this pattern would be quite a big change. And all the big changes are met with negativity/criticism, usually.

While negativity might be discouraging and sometimes might cross the line of a constructive discussion, at the same time it gives some food for thoughts. In this particular case, it gave me more to think about rather than 'looks nice'. So did this post https://news.ycombinator.com/item?id=6143604

Re: NProgress: slim, site-wide progress bars

#69

Post by bmelton »

rgrieselhuber wrote: post #64

Stripe used to do these and I always thought it was cool but there might be a good reason they stopped.

Similarly, there might be a good reason YouTube is still using them? As with all things, the pattern may or may not apply to any particular app or implementation.

That said, I'm not in love with them on YouTube. They always catch my eye for just a moment after they're done loading about halfway, and makes me crazy.

Re: NProgress: slim, site-wide progress bars

#70

Post by bmelton »

Lifebot wrote: post #41
Justsignedup wrote: post #35

Earlier quoted context omitted.

compu-what-tion? You mean accurately predict how long it'll take an ajax request to load? Pfft, an exercise in futility, easier to just fake it, and probably just as accurate :)

That's what confuses me. AJAX loaders are ubiquitous on the web. They're small, easy to use, and a great visual cue. I'm not sure why you would want a percent-based loading bar unless you actually knew how long something would take to load. (e.g. see loading bars for downloads) Using these super thin bars as a "dumb" loader seems like it would only confuse your users. It's like using an icon other than the floppy dis…

There are step functions that allow you to approximate it or increment it gradually. I might not know how long an individual step in a process will take, but if I know how many steps there are, I can know approximately how much to increment on the completion of each.

This doesn't suit all usage patterns (like file downloading where you don't know the file size), but I can think of at least a dozen scenarios in which this is perfectly suitable (even if I don't personally love the effect).

Post reply on HN