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