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

91–100 of 143 posts

Re: NProgress: slim, site-wide progress bars

#91

Post by gaelian »

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 personally think it's a nice looking solution and - as has already been said - I like the idea of a unified loading animation across an application.

But I'd like to see some actual user testing on whether this kind of progress bar does in fact show a typical user how long they have to wait or allows them to 'Time Travel'. In my own (anecdotal) experience, non-technical users are amazingly blind to small details on screen, sometimes even when they are changing/moving.

Re: NProgress: slim, site-wide progress bars

#92

Post by roryokane »

hadem wrote: post #85
ronaldx wrote: post #71

I find these fake progress bars a borderline-dark pattern: in general, the goal is to deceive users into waiting for progress that isn't truly happening, with the goal of holding their eyeballs.

How is this "fake"? I can set the exact percentage of the progress bar.

It’s fake because even after you set the exact correct percentage of the progress bar, the progress bar still keeps moving forward on its own, even if your process hasn’t made any progress. The page says it itself: NProgress has “realistic trickle animations to convince your users that something is happening” – even if nothing is actually happening. The stuttering-forward is all about looking like something is happening, when it that is not necessarily true.

Re: NProgress: slim, site-wide progress bars

#93

Post by roryokane »

platz wrote: post #43

So it just increments at random when you call Start, until Done is called (assuming setX isn't used)?

As far as I can tell, yes. Except that the bar stops incrementing at random right before it reaches the end, and doesn’t move forward even if you call `.inc()`. This is so the bar can still move forward when you call `.done()`.

Re: NProgress: slim, site-wide progress bars

#94

Post by jabr »

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 to use an asymptotic function for fake progress like this:

t/(t+n)

With n set to a bit under half the average load time, if generally looks about right, too.

Re: NProgress: slim, site-wide progress bars

#95

Post by Kequc »

grey-area wrote: post #4
k-mcgrady wrote: post #2

This looks really nice. I think I've saw one of the browsers using that space at the top for it's loading bar which looks very similar (I'm not positive on this - it could have been a mobile browser). Edit: Readme says it was inspired by Medium and YouTube - http://www.usabilitypost.com/2013/08/19/new-ui-pattern-websi...

The iOS7 browser has an identical progress bar. I saw it in a leaked screenshot somewhere, I'm sure :)

So what's the story here would one just look a little different from the other depending on colour choice?

Re: NProgress: slim, site-wide progress bars

#96

Post by voltagex_ »

swah wrote: post #53
infinita740 wrote: post #23

Earlier quoted context omitted.

This guy make fun of it in his flash games (progress bars go forward then backward) http://www.ferryhalim.com/orisinal/ Brings lots of memories, I used to make flash games in school when I was 15. I always liked those little games. /nostalgia

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?

Re: NProgress: slim, site-wide progress bars

#97

Post by mistercow »

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…

Yep, I use them pretty often now. What I would like to do is create a library for this. Features would include:

1. Choosing arbitrary time estimate to use as a target.

2. Providing distractions for if the estimate is much too low (show a secondary progress bar or spinner, maybe even misdirect so the primary bar can backtrack without the user noticing)

3. Calibration based on real results. A simple way would be to use linear regression to map the input guesses to real world results. Then the resulting equation should be easily available to plug into a persistence library or LocalStorage, so that you continue to get accurate results moving forward.

Re: NProgress: slim, site-wide progress bars

#98

Post by grinich »

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…

The iPhone SMS sending bar does the same thing.

Re: NProgress: slim, site-wide progress bars

#100

Post by lhadron »

Nice, but looking at the code I don't think really needs a jQuery dependency. Manipulating CSS classes, $extend, and the very basic DOM jiggering in this library could be accomplished easily without it. More and more people are removing jQuery in favor of frameworks like Angular and lighter weight libraries. Just my two cents.
Post reply on HN