Hacker News Reader

Comment by swombat | Hacker News Reader

Moreover, if you change the UI, people might notice changes that aren't even there. For example, we recently added an upload speed indicator ( http://woobius-dev.posterous.com/connection-information ), and as a result people have commented that the application feels faster.

Conversely, when we allowed people to interact with the data that was already loaded without waiting for it to refresh (via a clever sync mechanism), the first impression was that it was slower, because people things appeared to change unexpectedly while they were using the app. We had to add loading spinners back in so that the user would be aware that the application is still doing something, in order for people to actually feel that it was faster.

So, don't make just any UI change just for the heck of it - UI changes need to be as carefully considered as under-the-hood changes.

View on HN

http://www.chrisharrison.net/projects/progressbars/ProgBarHa...

This is a great paper on how Progress Bars affect our model of the computation. It looks at how our natural model of time is non-linear and how this can be used to make us feel that that system is faster.

The gist of the conclusion (from my super brief skimming) seemed to be that users hate long pauses as you get close to the end of a progress bar, and are much more tolerant of them in the beginning. If possible, you should optimize the progress bar to get possibly slow and sticky stuff over with at the beginning, and move smoothly and quickly as you reach the conclusion.

What about having it actually correlated to progress?

That's crazy talk.

It's not crazy talk, but it is, often really hard.

Any part of a process which has variable time or is at all out of your control is going to fuck it up.

Only if it's entirely unpredictable. Most of the things happening while most progress bars are, er, progressing (or not) are pretty predictable. I bet that at least 95% of bad progress bars could be improved considerably; whether it would be worth the trouble is of course a different question.

But how often is a progress bar actually related to "progress" in the simplistic sense, like sorting through a bunch of identical items?

More often we use progress bars to represent progress through a multi-step process, each one of indeterminate duration. This IMHO is a mis-use of the progress bar.

A far better way to do it is to show the user the steps you are moving through, and have an individual progress bar for each (if performance is expected to be linear), or simply an activity indicator. Check/grey items out as they become completed.

[edit] Another note: A lot of times progress bars are not backed up by correct code. For example, if you are, say, compressing a bunch of files - the progress bar should not represent how many files you have finished, but rather the size of those files. Too often progress bars are used to signify a quantity that is not closely correlated with TIME.

Exposing the steps and having them each have their own progress bar or "reset" the progress bar is always preferable to me as a user, both because I like feeling like I know what my software is doing (even -- or, in some cases, especially -- if it is behind the veneer of plain speech and a nice UI), and also the more fine granularity feeds my boredom and often does "make it seem quicker." If you have something to look at and track, you don't feel like it could take forever. Letting people see the light at the end of the tunnel /always/ makes it more bearable. Giving them "sub-tunnels" helps that further, I think.

Another example of this is online checkout paths. Obviously the fewer pages and fewer form fields a user has to fill out, the better, but even if its just a single page and a confirmation page, I /always/ prefer checkout paths which list the number of steps and number of pages at the top, and indicate how far along in the process I am. It's always so exasperating when online shopping when you think you're about to make a purchase, only to be taken to an unexpected "confirm everything you just did" page, followed by two order confirmation pages. Its not the same as an installer or other crunching process, but granulated progress bars get you a surprising amount of mileage in many linear processes you can put your users through.

I also apparently really like writing the word "always" surrounded by slashes. What's up with that.

I read them as italic.

Is it known who created the progress bar?

Or make the only "work" behind the last 15% of the bar a timer.

Reply on news.ycombinator.com