Hacker News Reader

Comment by blauwbilgorgel | Hacker News Reader

I tried to recreate this effect in raw JavaScript.

http://fiddle.jshell.net/zuBDW/2/show/

It doesn't load new content with ajax, nor does it pre-fetch. It just shows a website loading bar. I think this UI element is very nice. Especially for heavier pages, showing a website loading bar might combat users leaving, as something is happening.

For Ajax-loading I think it is a nice alternative for a center-center spinner.

View on HN

The importance of something happening is actually quite important for many users (I've found). An absurd example of this can be found in one of my one-off projects: http://gifmachine.xwl.me

The first version of this didn't have any kind of gloss, just 2 text inputs and a "go" button.

I showed it to some people I know and their immediate recommendation was to have some feedback to see how long things where taking. However, I didn't have any kind of a way to actually tell the user how things where going, so I took the next best approach: I fake it.

If you look at the source code, you'll see that when you press the "make a gif" button it starts loading the loading bar. That loading bar is totally useless, as it is entirely client side and shows no progress at all.

But people love it! Everyone I showed it to said it was a big improvement, making it nicer to use.

Even though it's a fake loading bar.

It is an improvement:

1. It lets you know that you clicked the go button correctly and that the computer isn't waiting for more input (perhaps you could disable the inputs as well).

2. It gives a user a reasonable expectation of how long the process should take i.e. it's not instant and they have to wait a bit.

(Clicking on "Make a gif" without putting in any input at all takes me to a non-existent gif: http://i.xwl.me/9539b2.gif)

The internal console at the company I work for has something like this (although it admits to being fake). The only complaint I have about it is that if the operation actually hangs, the bar reaches the end and just sits there, which is somewhat problematic.

I [fake upload progress][demo] for browsers without xhr2. To be consistent with the unknown file size and progress, the bar progresses asymptotically, and thus can never reach the end. It is also consistent in perception with what the user expects: a short upload has a fast bar (because it doesn't stay long enough to be slow) and a longer upload has a slow bar (because the fast part is comparatively much shorter in duration compared to the slow one). It is also consistent on the final part, i.e when it jumps to the end: if it was a small file, the bar was cut early yet growing fast it is expected to cross a bigger chasm.

[demo]: http://codepen.io/lloeki/pen/ydmCh

On OS X and iOS there are two different kinds of progress bars. Normal progress bars and indeterminate progress bars. Normal progress bars are used when you know the actual progress. Indeterminate progress bars are used when you don't know the actual progress and you don't know how long it will take.

Here is a video showing an indeterminate progress bar:

https://www.dropbox.com/s/mko66awdbwy6xzu/pb.mov

This is similar to bootstrap's .active.progress-striped progress bars[0].

We use bootstrap already, but I wanted the user to feel a sense of progress, whereas the indeterminate ones merely give a sense of action.

The iOS Messages app has a SMS progress bar that is totally fake: its duration is actually the mean duration of the last time it took to send SMSes, and is made to fill up to ~80% in that duration. It takes advantage of the knowledge that the exact same task takes about the same time. So despite being fake, its progress statistically makes sense and gives valuable, quantitative feedback to the user.

[0]: http://getbootstrap.com/2.3.2/components.html#progress

Am I the only one who thinks fake bars are an awful idea? If you don't know how long the operation is going to take, why not just use a throbber or an oscillating bar or something? A fake bar just messes up the conceptual model that people build while using the app. Especially when the thing is broken for some reason.

I was thinking this should be position fixed in case you are scrolled half way down the page - you would not see the position absolute bar at the top, but it should be attached to the browser navigation right? The issue with position fixed is getting it to span the full width... any thoughts - maybe my UI sense is wrong here too?

[edit] Actually, doing a little testing on it now - position:fixed seems to just work. I like this solution a lot need to test it out... would be great to attach this to xhr progress events...

Yes, good catch. If you want to recreate the Youtube bar, you'd need position fixed. For this faux-progress bar, position absolute works most of the time, because you usually load a new webpage without scrolling down.

Keep in mind though that if part of your loading time is parsing large amounts of JSON returned from your backend, this blocks the main thread and your loading bar will be stuck for that time.

This is where web workers will come in handy. I did a little promo video tutorial on loading data with Flickr using web workers. You can watch that at http://www.youtube.com/watch?v=4eDl1UOkp18&feature=c4-overvi...

I can't wait for those to be useful everywhere.

Are there any implementations of a task queue using web workers? It would be cool to have something where you can just decorate a function to do it on the web worker's thread instead of have to manually write the postmessage and onmessage stuff and have a separate worker.js

This would be nice for long-running requests (i.e. payment submissions).

Reply on news.ycombinator.com