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

111–120 of 143 posts

Re: NProgress: slim, site-wide progress bars

#111

Post by dclowd9901 »

Justsignedup wrote: post #35
Lifebot wrote: post #24

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?

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

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

Re: NProgress: slim, site-wide progress bars

#112

Post by chavesn »

benburleson wrote: post #7

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

I think the problem was that SWFs so frequently needed load indicators. Sure, progress bars make the time seem to go by quicker, but what's better is actually being quicker. Progress bars were a crutch, but the pages were still dramatically slower, that's why we all hated Flash sites so much.

Re: NProgress: slim, site-wide progress bars

#113

Post by mafro »

wfunction wrote: post #109
jjcm wrote: post #77

Earlier quoted context omitted.

I work for Microsoft as a UX prototyper. One of the research studies we did was something similar to this a while back. One of the findings we had was that if there was any motion at all on the screen, the user felt something was happening. It didn't have to be prominent, just noticeable. If you're doing voice input on windows phone, the vu meter is just a series of very small dancing dots. To let the users know that…

Is this also why Explorer's progress bar approaches the end asymptically, with no regards to the actual number of files processed? It drives me NUTS, to say the least.

I always knew there must be some solid UX reasoning behind those file copy dialogs.

Re: NProgress: slim, site-wide progress bars

#115

Post by n1ghtmare_ »

lelandbatey wrote: post #81
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…

This is 100% true. I shared this story in another comment yesterday, but I'll share it again here: On one of my one-off side projects( http://gifmachine.xwl.me/ ), there's a rather silly example of the importance of loading bars. In the first version, the design was quite bare. There were a couple of textinputs and a "make gif" button. The way the code happens to work, when you press the "make gif" button the web pag…

I like your app, it's very cool. One thing though, make sure you add some validation on the fields. Right now when I click on "Make a gif" without anything populated, it loads to some point and throws an error.

Re: NProgress: slim, site-wide progress bars

#117

Post by mseebach »

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…

Sometime around the turn of the century, I worked on an enterprise webapp (of the kind I fear may have kept IE4 in production for a long time). We'd show a popup-window with a gif of spinning gears for operations that took more than a few seconds.

At one point, we had a call from a user that had been waiting for one of these operations to finish for a long time. We looked into it and realised that some backend process had crashed, so we restarted it and told him he'd have to reload the app. The user wouldn't hear it - it was still working, he could see the gears turning!

Re: NProgress: slim, site-wide progress bars

#119

Post by WA »

lelandbatey wrote: post #81
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…

This is 100% true. I shared this story in another comment yesterday, but I'll share it again here: On one of my one-off side projects( http://gifmachine.xwl.me/ ), there's a rather silly example of the importance of loading bars. In the first version, the design was quite bare. There were a couple of textinputs and a "make gif" button. The way the code happens to work, when you press the "make gif" button the web pag…

I have an app that does some prediction based on values that a user enters. The prediction works pretty fast – unnoticably fast, like 50ms or so.

However, I had the idea to use a progress bar to achieve the opposite effect: To introduce an artifical waiting time together with a sense of progress (hence, progress bar). This should convey the feeling that the app is working hard to make Your Personal Prediction and since the app appears to be calculating a lot of stuff, the prediction Must Be Totally Accurate.

Surely, the target users are not necessarily sophisticated technical people.

I haven't implemented it but I definitely want to try it out.

Re: NProgress: slim, site-wide progress bars

#120

Post by dspillett »

jjcm wrote: post #77
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 work for Microsoft as a UX prototyper. One of the research studies we did was something similar to this a while back. One of the findings we had was that if there was any motion at all on the screen, the user felt something was happening. It didn't have to be prominent, just noticeable. If you're doing voice input on windows phone, the vu meter is just a series of very small dancing dots. To let the users know that…

> I work for Microsoft as a UX prototyper.

Please could you talk to the IE team about their progress bars explicitly lying to the user? I understand that giving immediate feedback is important as it can greatly increase perceived responsiveness, but that damn thing (on both desktop and Windows Phone 8) can climb to ~80% before even the first byte is received (it might even manage ~80% before the DNS lookup has returned though I've not tested to prove that). Have you every tried explaining to a non-technical user that their phone didn't "get nearly all the way then stopped" when loading a page? They simply don't believe "your web browsing software is lying to you, it didn't actually receive anything" and look at me as if I'm making things up to try hide that I simply don't understand the hinterwebs.

Of course the lie works: people think IE is more efficient than other browsers simply because on slow site and/or with slow connectivity the progress bar seems to initially push up faster than the one in FF/Chrome/other even though the actual page load time is the same.

I'm fine with little white lies to make the user feel more cared for (which is what fast "apparent response times" is all about: people personify technology so if you don't give the impression of immediate response they feel like some concious entity is actively ignoring them) but the IE progress bar takes that to an irritating extreme, to the point where it is detrimental to UX (I sometimes can't tell if the page is just loading slowly or nothing is transferring at all and I'm just going to get the "page not available" error in 20 seconds time).

It irritates me enough that it will be a factor in deciding what I buy when my current smartphone needs to be replaced (much as I like the Lumia 920; this, other Windows Phone annoyances, and comparative inexpensiveness, will make it difficult to justify not switching to Android next time).

Post reply on HN