221–230 of 232 posts
Earlier quoted context omitted.
I don't think you are in disagreement.
Neither of Jeremy Bank's sentences are relevant to my first comment if you try to contort their interpretation so they do not conflict with me.
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…
At my first job we made training simulations. One day someone decided to do make our loading bar more accurate by splitting loading into several segments and keeping a local record of the average time to load each segment. The result was a smooth progress bar from 0 to 100. We were proud of it. Years later I worked on a popular AAA franchise and we had replace our loading screen spinner with a progress bar due to con…
Earlier quoted context omitted.
Neither of Jeremy Bank's sentences are relevant to my first comment if you try to contort their interpretation so they do not conflict with me.
To me, JeremyBanks' second sentence clearly implied that users don;'t trust progress bars anymore, and your comment was unnecessary. He is also certainly implying that lying is not OK. Interpreting them otherwise seems like a strange kind of contortion to me.
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
At my first job we made training simulations. One day someone decided to do make our loading bar more accurate by splitting loading into several segments and keeping a local record of the average time to load each segment. The result was a smooth progress bar from 0 to 100. We were proud of it. Years later I worked on a popular AAA franchise and we had replace our loading screen spinner with a progress bar due to con…
The failure mode becomes the bar stops at 99 or 100 but the game doesn't run, or worse, the bar flies off the end of the chart, hitting 101%, 102%, etc...
-Done
-80% done
-if the CPU for a given process drops below 10%
The CPU tool works for Mac OS installers and anything else. Works decently on Linux too. I call my tool SpookyLoop: http://142.93.117.219:5000/
The article teases at the indeterminism of ops on different computers, and also the halting problem at the theoretical level. But an exact estimate isn’t a necessary experience. I contend that the ultimate UX is going for a walk and doing something else afc with some confidence that you’ll be ping’ed when it’s time to return. Beyond that, predicting time-to-complete becomes an opportunity to create trust in a brand. I’d much prefer a text message when the install is done than checking my TeamViewer every few minutes while on the go. If a software can provide that, I’d value that more than a data driven estimate that still might be wildly off
Proposal 1 is the thing I want. Please just list out a total number of steps and log when each of those steps is completed (with a short message describing what the step is so that we don't end up back on square one with fractional progress bars). If possible make the steps granular enough so that a step can be completed in under a second (so this may be hundreds or thousands of steps depending on the task length). I…
Itemizing individual steps allows users to reason about their performance characteristics, if well explained. These might cause jerkiness in the overall bar.
If I had a progress bar stuck at 27%, it would be valuable to click a little "view more" link and see "11:34 AM: begin downloading file 27/100: foo.tgz (62.3Gb)" I'd be more willing to expect to wait on it advancing than if it was a 30k file.
A long long time ago, I was testing a web site. I accidentally suspended the server. Mozilla's progress bar stopped right there while internet explorer kept going, progressively slower, until the browser threw an error around 98%. Also, let's not forget windows file download/copy estimations. Lying progress bars are at least as old as windows.
Earlier quoted context omitted.
The failure mode becomes the bar stops at 99 or 100 but the game doesn't run, or worse, the bar flies off the end of the chart, hitting 101%, 102%, etc...
Neither of those could happen since it was capped at 100 and the time to fill it was just below the timeout.
> Every time I upload a lecture video to YouTube, it goes back-and-forth from "0% processed" and "100% processed", repeatedly, until it is actually done. I've never seen it say any other number. I’m uploading a couple of 50–100m videos each week, and a lot of the time it stops off briefly at 95%, 99% or both before reaching 100%. (Also, “100% processed” comes before “finished processing” or “SD processed, processing…