Re the response in the post, I think your “10% flakey” argument is sort of ad hominem - of course a poorly-implemented hi fi feature is worse than a well-implemented lo fi feature. In that case, the quality is as much a function of the implementor as the feature.

So yes, perhaps there should have been a barbershop pole in the specific case, but the real lesson, IMO, is to work within your means, not that barber shop poles are “better”. An equally viable (and many times preferable) method for working within your means is to change your means rather than your work, as illustrated by recent decisions ;)

very well, i shall update the post to reflect this. in this particular case, i’m still pro fake progress bars because the company had bigger fish to fry, UI-wise and backend-wise, and we would have gotten substantial mileage out of the cheap fake solution.

as “not huned” above notes, there are cases where both are appropriate.

also note that we had 5mb filesize limits at the time the progress bar was implemented.

An unmentioned problem in our case was that the timeframe was uncertain: it was a media upload form, accepting files up to 8Mb large. For a dial-up user, that could be a long time, and a fakey progress bar might start to look like a hung process. Anyone who has used a low-RAM Mac can attest to the frustration associated with starring at the very-long-fakey-thought-in-progress-color-wheel, unable to figure out why the system is hung. Given that consideration, we opted for a real progress bar.