Ok it's not entirely perfect but worked fine for a database population program. When I say fine I mean I could tell if it was going to complete before I wanted to leave for the day.
The original post states that "less than a minute" is being showed however makes no mention of the status of the progress bar. This is the fundamental mistake as the progress bar position and the time remain are almost independent items. Yes they should be linked as closely as possible but as stated in lots of other comments things change overtime and therefore can not be predicted.
I would suggest that the following implementation of a progress bar is more sensible.
Firstly, work out your operations and give them a waiting (waiting can be called an atomic operation). With file upload/download this is straight forward but for other operations you may just resort to giving them all a waiting of 1.
Second you can have 4 types of progress 1. The number of operations complete out of all the operations you need to perform (represented as a progress bar) 2. The number of atomic operations complete out of all the atomic operations (represented as a progress bar) NOTE. If you have wait operations which don't have progress in themselves then your progress bar will jump, e.g. if you have give a 50% waiting to one task but can't tell how far that task is through. 3. The time remaining based on the number of atomic operations remaining over the total number of operations remaining and duration form the start of the process. (This is inaccurate as for a long process which slows at the end you will get the 1 minute remaining scenario) 4. The time remaining based on the number of atomic operations performed in the last period e.g. 1 minute, extrapolated into the time taken to perform the rest. (This give a more accurate representation of current progress)
Personally I think showing 1. and 4. gives the most feedback to the user and although the time may go up (as we see with download times) the progress bar is still accurate.
Slashdot Mirror
Ok it's not entirely perfect but worked fine for a database population program. When I say fine I mean I could tell if it was going to complete before I wanted to leave for the day.
The original post states that "less than a minute" is being showed however makes no mention of the status of the progress bar. This is the fundamental mistake as the progress bar position and the time remain are almost independent items. Yes they should be linked as closely as possible but as stated in lots of other comments things change overtime and therefore can not be predicted.
I would suggest that the following implementation of a progress bar is more sensible.
Firstly, work out your operations and give them a waiting (waiting can be called an atomic operation). With file upload/download this is straight forward but for other operations you may just resort to giving them all a waiting of 1.
Second you can have 4 types of progress
1. The number of operations complete out of all the operations you need to perform (represented as a progress bar)
2. The number of atomic operations complete out of all the atomic operations (represented as a progress bar) NOTE. If you have wait operations which don't have progress in themselves then your progress bar will jump, e.g. if you have give a 50% waiting to one task but can't tell how far that task is through.
3. The time remaining based on the number of atomic operations remaining over the total number of operations remaining and duration form the start of the process. (This is inaccurate as for a long process which slows at the end you will get the 1 minute remaining scenario)
4. The time remaining based on the number of atomic operations performed in the last period e.g. 1 minute, extrapolated into the time taken to perform the rest. (This give a more accurate representation of current progress)
Personally I think showing 1. and 4. gives the most feedback to the user and although the time may go up (as we see with download times) the progress bar is still accurate.