NProgress: slim, site-wide progress bars

Re:NProgress: slim, site-wide progress bars by Lifebot on Tuesday August 20, 2013 @04:56PM (#6246496)

Question for people using these progress bars: Are you actually doing the computation to accurately estimate the time it takes to complete the action indicated by the progress bar, or are you simply showing a progress bar as a visual cue to any loading in the same way people have been using spinning AJAX loaders?

[ Parent | on HN ]

Re:NProgress: slim, site-wide progress bars by Justsignedup on Tuesday August 20, 2013 @05:07PM (#6246575)

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 :)

[ Parent | on HN ]

Re:NProgress: slim, site-wide progress bars by Lifebot on Tuesday August 20, 2013 @05:13PM (#6246620)

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 disk to convey saving.

[ Parent | on HN ]

Re:NProgress: slim, site-wide progress bars by bmelton on Tuesday August 20, 2013 @06:38PM (#6247056)

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).

[ Parent | on HN ]

Re:NProgress: slim, site-wide progress bars by dclowd9901 on Wednesday August 21, 2013 @01:27AM (#6248379)

It's not that hard. If you're already using a module loader (which in all likelihood, you are if you're loading something async these days), then just count modules being loaded in your controller(s), and use that as your basis.

A harder approach would be to be super accurate with actual size of response. Content-length on the header won't work because it only refers to that one file. Also, the server won't have any clue which files belong to which web page response. A way around this is to check every request against a session ID. You'll also have to pass back some sort of "request hash" -- GUID for the request so you can match different files from the same request (static files, content, etc).

[ Parent | on HN ]