Comment by quickthrower2
7 years ago
Reminds me of the old IE bar (not sure if it still does this), but it would crawl towards 100%, getting slower and slower as it approached the end, when waiting for a page to respond. In reality IE had no idea how much "progress" had been made by the server, if any.
They also had those progress bars when you stopped or restarted some services in an old version of Windows. They had no idea how long it would take, so they just made a logarithmic progress bar that became slower and slower, but never finished.
That trick only works once. As soon as you see that progress bar pattern a couple of times, you realise that it is fake, and it is infuriating.
Progress bars need to be honest. If you don't have any clue how long it'll take, show a spinner instead.
I'd rather just see output of something tied to the actual process.
Basically an answer to the question, "Is this thing taking a long time because it's doing work - or because it's busted"
In software it's busted at least 20% of the time and I think that's being generous.
Chrome for Android does the same thing. If you start loading a page, then disconnect your phone through your router (with mobile data off), the progress bar will continue to move until your phone realizes that you no longer are connected to wifi.
Same as Explorer, the file browser. Once you know, it's useful as a timeout meter, i.e. it signals "how long before this device/network location is deemed unreadable".
Wouldn't an actual timeout timer be more useful, like when Ubuntu is booting/shutdowning it gives a "job is trying to complete" message and a 90s (say) timer before it ignores it and carries on.
Windows updates could use this, when it randomly decides to wait 30 minutes on startup despite not warning you and not giving a skip option.
Windows still does this when searching the hard drive.
The SMS sending bar on old phones used to just take four seconds to go across, then stop at 95% if it wasn't done yet.
The iPhone did this, and then when they added iMessage originally it would still use the same tactic even if you were sending say, a large video (in which case the software obviously should know how much has been uploaded so far). I guess their internal API for "send a message" was not properly updated to take into account multimedia.