[TeMPOraL]

Strongly agreed.

One tricky thing, though. The few times I saw someone trying to implement the task count, it would sometimes be the case the count couldn't be determined beforehand! So I'd see progress reports like: 1/123 done.... 42/124 done... 45/2616 done... 68/98213 done...

I think scandisk (or whatever the disk scanning utility that runs before Windows boots is called these days) was prone to such ever-growing task counts. I don't know what the right answer here is, except maybe try to split your process into a "planning" part and "execution" part if possible...

[Ruthalas]

Honestly, the example with the incrementing total, while not useful for estimating remaining time, conveys a lot of information. I'd be happy with that for processes that have an unknown number of steps.

[hutattedonmyarm]

> One tricky thing, though. The few times I saw someone trying to implement the task count, it would sometimes be the case the count couldn't be determined beforehand! So I'd see progress reports like: 1/123 done.... 42/124 done... 45/2616 done... 68/98213 done...

SharePoint search does something similar! It doesn't search everything, so it just says "about X items found" based on an estimate. Everytime you click on the next search page, that number gets a little more accurate

[TeMPOraL]

This reminds me - GMail does something similar in their search/filtering interface too!

[gpvos]

> split your process into a "planning" part and "execution" part if possible

Doing the scanning and the processing at the same time may be faster. It should be clear though when the total has been established and when it isn't yet.