Jump to content

  • Log In with Google      Sign In   
  • Create Account


Progress Bars


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
27 replies to this topic

#21 serioso   Members   -  Reputation: 347

Posted 25 April 2013 - 01:58 PM

There is an art to making good progress bars.  It takes a lot more time and effort than anyone is ever willing to put into it, and as a result they are often overlooked.

 

There is something inherently pleasing about watching a good, well-designed progress bar load to completion.  I've thought about this quite a bit before, and for some time, I've become rather obsessed with them.  I would download and install a bunch of things I didn't need just to watch progress bars.  I share my conclusions below.

 

The motion of an ideal progress bar should resemble the plot of a novel.  It's not terribly interesting to watch a progress bar zip right through to the end without encountering a hint of difficulty along the way.  Would you enjoy reading a novel that didn't have a plot or an antagonist?  That would make for a boring novel!

 

The progress bar should start off confidently, ramp up some speed, but slow down around 15-30%.  It doesn't mean stop - you don't ever want a progress bar to stop entirely - but it should start to visibly struggle. It should not stutter or jump around violently or go backwards or anything like that, but its progress should become unsteady.   It should come in waves.  These waves should build up overtime.  It you got some things you need to load that you're uncertain about time-wise, the 30-80% range is the ideal time to load those things.

 

The climax portion is the most important part.  This is where shit gets real.  You should slow that sucker to a crawl (but don't you dare stop it entirely or I will find you).  If you're printing out any sort of details about what's loading, this is the part where you start spitting them out rapid-fire.  Make it up if you have to - write you're "Reticulating splines" for all I care - if you do it right, I won't have time to read it anyway.  If you're thinking about writing to the hard drive, this is the time to do it - make some noise with it.  If you don't have anything you need to write, implement a hard drive stress test algorithm and run it during the 80-95% range.

 

Don't you dare let me down in the last 5%.  There is nothing more disappointing than a progress bar that just disappears when it reaches 99%.  If you do this, I will go to your house and tear out the last page of every book you own.  If you get nothing else from my rambling, at least remember this, because it should be relatively easy to implement, but it needs to be done deliberately: Pause - for just a brief moment, pause when you reach 100%.  Will you promise me that you will do this the next time you implement a progress bar?  Just put a Thread.Sleep(500) in there once you get to a 100%, that's all it takes - but it makes all the difference in the world.  Don't make it too much shorter than 500 ms, or it will look like it just disappeared, but not too much longer, because you never want a progress bar to hang.  A half-second delay to give some closure to the ordeal, that's all.  Please do it.

 

So there you have it.  I hope we can all walk away from this being slightly more attentive to these finer details of the user experience and give progress bars the attention they deserve.  Thanks for reading.



Sponsor:

#22 Paradigm Shifter   Crossbones+   -  Reputation: 5094

Posted 25 April 2013 - 04:49 PM

I think you need to get out more ;)


"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#23 unbird   Crossbones+   -  Reputation: 4727

Posted 25 April 2013 - 05:21 PM

Nah, he can "play" this



#24 BlueSalamander   Members   -  Reputation: 615

Posted 25 April 2013 - 05:52 PM

The crazy thing about progress bars is that their very presence slows down the process that they are informing you about. I use one in my new game for the process of loading file & folder names inside a given folder. But the process is much faster if I don't display the progress bar.



#25 Bacterius   Crossbones+   -  Reputation: 7970

Posted 25 April 2013 - 06:05 PM

The crazy thing about progress bars is that their very presence slows down the process that they are informing you about. I use one in my new game for the process of loading file & folder names inside a given folder. But the process is much faster if I don't display the progress bar.

 

You're probably doing it wrong then. You shouldn't be updating the progress bar hundreds of times a second - only update and display it once there has been sufficient progress for it to display something new, and if the task is sufficiently long that it deserves a progress bar to begin with. Also, you probably don't need pixel accuracy on a progress bar - even the old Windows 95 progress bars were good at what they did and had sufficiently large discrete steps that it was only necessary to redraw them a handful of times:

 

fake-progress-bar-6.jpg

 

Inside the code logic, you should only be updating a variable called "progress" or something like that, then redraw the progress bar component if drawing it would cause the currently displayed progress to change :)


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#26 Luckless   Crossbones+   -  Reputation: 1579

Posted 25 April 2013 - 06:06 PM

Sure. But a lot of the time when stuff freezes, or the window becomes unresponsive, those UI elements keep ticking away.

 

I test software at work, and one project (an iOS app) had all load indicators fail one build. Trust me, that was hellish to use as it constantly felt like the app had locked up and crashed. (Something that it frequently done in pervious builds due to being so early in development.)


Old Username: Talroth
If your signature on a web forum takes up more space than your average post, then you are doing things wrong.

#27 Amadeus H   Members   -  Reputation: 1180

Posted 26 April 2013 - 12:14 AM

To share some recent experience!

 

We did some user testing when implementing an installation bootstrapper (installing tons of big packages) last autumn, and when there was both a normal progress bar and a spinning wheel at the side the users felt that the installation was faster than with just a normal progress bar. And a lot faster than only a spinning wheel. The worst user experience though came from the indeterminete progress bar though, which is interesting because it's as useless as the spinning wheel. But maybe not as pretty!



#28 LancerSolurus   Members   -  Reputation: 480

Posted 26 April 2013 - 12:37 AM

I use a progress bar but only update it between stages. I don't see the need to update it for every file loaded, only when a particular step in the initialization stage is complete. In a way it is a 'lazy' update but it does let the user know something is actually progressing. I don't bother with showing what is going on internally but it does show about 30 steps worth. Since I've implemented that perceptually it seems as if the loading time is much shorter even though I know it is a few ms longer than before due to the draw code.


******************************************************************************************
Youtube Channel





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS