111–120 of 232 posts
You know what I like for progress bars? The mess that is your average build script. Tell me how many tasks there are to complete, how many you've done, and some rough details of what you're doing (e.g. is it a network request). Don't be shy about commentary ("This may take a while", "If this fails multiple times do X"). These generally contain all of the information that the developer has access to, and rarely am I l…
CMake has a progress indicator.
Earlier quoted context omitted.
Especially fun in Web UIs where the callback that would remove the spinner will never be called because some error occurred somewhere in between and is only logged in the console where no normal user will ever see it ... Personally I feel that to be very much a subversion of the »things are still moving, so stuff is still happening« assumption that has been common in normal desktop applications.
Maybe spinners like these need a kind of "dead man's switch", where something needs to keep telling them "yep, still working" every so often, otherwise an error is shown?
Getting something like a callback for progress would require modifications all the way down the stack, akin to what's needed for fully async code.
A good solution is to have a progress bar that goes for a certain amount of time 0->10 seconds. But if it finishes earlier, then it quickly jumps to 100%.
Still a lie, but it's satisfying to watch and accurately finishes every time (so it's harder to spot the lie).
Earlier quoted context omitted.
I've gotten real good at recognizing those kinds of progress bars; I think Window Explorer's search had one and it trained me to never trust them.
I recently found out that you can prepend your search with "name:" and windows search will only match against filenames which is the behavior most users expect by default and much faster than whatever nonsense windows explorer search normally does. Example: name:search-term
Earlier quoted context omitted.
You're bringing up the easiest use case though. Most complex flows cannot be easily expressed by a single determinable metric.
Complex flows can be represented by a tree control full of checkboxes that tick off for things that are done, which can be hidden behind a "show details ..." button next to a regular progress bar. If the users can see the detailed tasks, maybe they will be less ticked off by a jumpy progress bar.
Progress bars are something that have been researched and iterated on for decades now, and the overall sentiment is pretty clear – users like seeing numbers go from zero to a hundred while they wait. It doesn't matter if they aren't always accurate. Replacing them with a static "processing" message would absolutely increase user confusion and dissatisfaction with loading times. A while ago we put in a lot of engineer…
As another commenter pointed out, static "processing" messages are indistinguishable from "your system is hung". I think the best option is simply X/Y bytes downloaded, like Blizzard does on WoW patches. The fraction indicates how much is left to download, and the rate of the numerator changing informs how quickly the download is going.
This is an important point. "Lying" progress bars are still conveying essential information - that the installation is progressing and isn't frozen. I remember from my days working with W98 and early Ubuntu versions, one of the most important bits of information coming from progress bars was whether or not the whole thing was frozen and needed the power cord pulled.
Progress bars are something that have been researched and iterated on for decades now, and the overall sentiment is pretty clear – users like seeing numbers go from zero to a hundred while they wait. It doesn't matter if they aren't always accurate. Replacing them with a static "processing" message would absolutely increase user confusion and dissatisfaction with loading times. A while ago we put in a lot of engineer…
Earlier quoted context omitted.
Lying often reduces complaints. This doesn't mean users like being lied to, it means they don't know they are being lied to.
Users aren't being fooled here. People learn that progress bars aren't accurate, and things like the author mentioned, "when it gets to 75% it will really be done".
Earlier quoted context omitted.
As another commenter pointed out, static "processing" messages are indistinguishable from "your system is hung". I think the best option is simply X/Y bytes downloaded, like Blizzard does on WoW patches. The fraction indicates how much is left to download, and the rate of the numerator changing informs how quickly the download is going.
> As another commenter pointed out, static "processing" messages are indistinguishable from "your system is hung". This is an important point. "Lying" progress bars are still conveying essential information - that the installation is progressing and isn't frozen. I remember from my days working with W98 and early Ubuntu versions, one of the most important bits of information coming from progress bars was whether or n…