5 ms·
Both still look like they're still moving when they're stopped though, which is the real point of them. Tricking the user into believing the task will be comple
by trotsky 16y ago
Both still look like they're still moving when they're stopped though, which is the real point of them. Tricking the user into believing the task will be completed before it really will be isn't the goal - otherwise they'd intentionally underestimate completion times when they're displayed.
- DougBTX 16y agoI think that actually is what they are designed to do, make it look like it is going to be completed sooner. If you just underestimate completion times, the you'll have a 100% complete bar while still making the user wait - that will make it look broken and slow, the opposite effect. Better to overestimate, then the task will be completed "early" because it was so "fast".
- InclinedPlane 16y agoThis is exactly how people perceive execution time. If a progress bar goes to completion and then hangs users will perceive that operation as taking longer than if a progress bar goes to, say, 70% and then jumps to completion, even if the total time of the operation is the same. It makes sense though, people are the most impatient when they've been waiting the longest so being surprised that the operation completed faster than they were led to think it would is more welcome than having to wait longer than they thought they'd have to.
- sesqu 16y agoVista SP1 changed the file copy algorithm to cache files, so that it would appear faster than it is (and other reasons): http://www.codinghorror.com/blog/2008/03/actual-performance-perceived-performance/comments/page/2/ http://www.codinghorror.com/blog/2008/03/actual-performance-...