Wouldn’t accurate progress bars solve the unsolvable halting problem?[0]
Progress bars still lie
201–210 of 232 posts
Re: Progress bars still lie
#202Earlier quoted context omitted.
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
Windows Explorer, IIRC (I don't use Windows anymore), searches the content and title of most(?) files.
It's not just search when the progress bar appears, though. Also when trying to enumerate contents of a folder - e.g. when you're accessing a networked resource, or one that may not be viewable with your privileges. You then get this bullshit progress bar that speeds through the first 3/4, and asymptotically approaches 100%.
Re: Progress bars still lie
#203Earlier quoted context omitted.
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?
Then the `try { ... } catch { heartbeat() }` pattern will emerge.
Which is a sane pattern if a language has proper destructors (a seemingly non-existent thing in GC-enabled languages, unfortunately).
In C++, you'd stack-allocate an object representing a spinner, that spawns said spinner in its constructor, and deletes it in its destructor. Then the spinner doesn't outlive the processing code, no matter what path execution took to end the processing.
There are similar patterns in GC-enabled languages ("with" idiom). Async does throw a wrench into this a bit, though.
Re: Progress bars still lie
#204Wouldn’t accurate progress bars solve the unsolvable halting problem?[0] [0]: https://en.m.wikipedia.org/wiki/Halting_problem
I mean yes, a universally accurate progress bar would be impossible, but that’s vastly different from a mostly-accurate application-specific progress bar. The point of the article is that most software barely even tries to give you something reasonable.
Re: Progress bars still lie
#205Earlier quoted context omitted.
Well... story time. I had to implement a lying progress bar at the behest of my client. We could not reliably predict much...network speed, file size, moon phases, sock colour, etc would change things all the time. The client wanted to show the customer that "things were happening"... so we made the bar always move. The logic was that once it hit 90% or more, customers seemed to be invested and would wait forever. An…
What's wrong with using something like a spinner in that case though? The big issue with a lying progress bar is that it not only lies when things are happening, it also lies when things are broken, possibly wasting a lot of your users' time.
Our most important users (read: $$$) were also the most sophisticated. They also appeared to like numbers... as numbers helped them when they complained back to us that our system sucked. If we took information (as bullshitty as it was) away, they accused us of hiding the truth. As Calvin said to the monsters under his bed... they lie, I lie. Our process was very heavily weighted near the end...so if you made it to 90%...and hung on, it would very likely finish. Again, you need to know your users and play to their strengths/weaknesses and track metrics.
Re: Progress bars still lie
#206You 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…
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...
Re: Progress bars still lie
#207You 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…
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…
> 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
Re: Progress bars still lie
#208Earlier quoted context omitted.
Totally agree. I was rather intentionally using examples from more than a decade ago, where I was using the progress bar to observe whether or not the whole system was hung. This was back when my best computer had a 500 MHz CPU and 512 MB of RAM.
There was never a time when >best computer had a 500 MHz CPU and 512 MB of RAM 500 MHz cpus started showing up in servers with 21164 in 1996 in boxes maxing out at 2GB ram, and on desktops with 1999 Pentium 3 plugged into 1998 chipset (440BX) already supporting 1GB.
Really all you need is 32 KB of RAM
Re: Progress bars still lie
#209Earlier quoted context omitted.
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…
> 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…
This reminds me - GMail does something similar in their search/filtering interface too!
Re: Progress bars still lie
#210Earlier quoted context omitted.
It's worse. They seem to be intentionally slowing things down to make it look like the software is somehow "working harder" because to some people it justifies the high price. A progress bar that takes 5s or more to complete for an operation that actually takes under a second.
Hell, the standard everybody seems to have converged upon is a mendacious progress bar where the user is not told what the percentage refers to (e.g., total install time? Number of files processed? Data left to be copied?). The frontend developer could show changing Matrix glyphs instead and the widget would be functionally equivalent but without giving the user false impressions.[1] Given that as a standard, it's di…
To me there's a big difference between intentionally slowing down the underlying operation (or the ability of the UI to go to the next step anyway) so you can show a longer progress bar, and just having a poorly designed uninformative progress bar on the underlying operation.
Not to you, really? I mean, I guess we can't argue about "how outraged you are", that's up to you.
Do you think those poorly designed progress bars are built to intentionally mislead? It's possible. For what end, do you think? The TurboTax one seems designed to intentionally mislead. Even if they both are, I still prefer one that isn't making me wait artificially longer than the software actually requires though.