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