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

121–130 of 143 posts

Re: NProgress: slim, site-wide progress bars

#121

Post by _s »

WA wrote: post #119
lelandbatey wrote: post #81

Earlier quoted context omitted.

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 sin…

We had this issue on our website - our "Browse" is essentially an SPA that fetches results from an API upon any action being taken; such as sorting, pagination, adding filters etc. We had the fetching and rendering happening in an average of 30-50ms, which meant most users didn't even realise the page had refreshed apart from what appeared to be a faint blink on the whole page.

We actually had to put in a setTimeout() for 500ms with a loading gif, followed by an scrollTo() to the top of the results just so users would know something actually happened.

Re: NProgress: slim, site-wide progress bars

#122

Post by tlarkworthy »

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…

Please make the bars predict accurately. For a hack its ok to cut corners, but the bars have been bad predictors since windows 95. You guys could have figured it out by now, surely? It has probably caused irritation 10^9 times by now.

It should be the first feature of windows 9. I would upgrade!

Re: NProgress: slim, site-wide progress bars

#123

Post by stephanos2k »

mseebach wrote: post #117
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 proces…

That's funny, true and sad at the same time.

Re: NProgress: slim, site-wide progress bars

#126

Post by swah »

voltagex_ wrote: post #96
swah wrote: post #53

Earlier quoted context omitted.

There aren't JS games close to this yet, right?

Apart from the art, is there any reason you couldn't do this in JS/HTML5?

In theory, yes. But my research indicates that you don't see smooth games like that yet.

Re: NProgress: slim, site-wide progress bars

#128

Post by coldpie »

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…

Online tax software like TurboTax does this as well. It says crap like, "Loading your profile from last year..." or "Verifying your data is correct..." with a bar that takes 5 or 10 seconds to fill up before highlighting the Next Page button. But you can just click the Next button anyway and it'll go instantly.

Re: NProgress: slim, site-wide progress bars

#129

Post by adyus »

chrisfarms wrote: post #54

Is this a part of a (very slowly) building trend towards a chrome-less browser? Long ago we used to "login" to a site using BasicAuth and the browser defined login box.... it wasn't flexible/pretty enough so we started using s and integrated them into the page. We had a path-like URL structure that we used to get to our documents, but our documents became more complex and the path-like structure became less human fri…

I think this direction can better be described as reaching toward a "native" experience, such as on mobile devices. You see this in Windows 8's full screen apps, they tend to be isolated containers, even though some are written using web technologies.

Re: NProgress: slim, site-wide progress bars

#130

Post by andyhmltn »

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.

Apple's 'sending message' bar (at least on iOS7) speeds right to the end and then waits about 50px before it for a few seconds before sending. It's so annoying!
Post reply on HN