81–90 of 232 posts
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…
Earlier quoted context omitted.
> In other words, the actual number is not important...what is important is real feedback that things are still happening and it's worth waiting. And the inverse is that when progress bars are fake , they tell the user that everything is working even when it's not! I MitM my SSL traffic. This causes Figma to fail to load documents in the most annoying way possible —it shows a progress bar that never stops moving, but…
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.
name:search-termProgress 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…
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.
Earlier quoted context omitted.
> Usually progress bars implicitly measure "time left", but the total isn't known in that case, so progress bars are inapproprate. Are you sure about that? I'd argue that most progress bars explicitly measure tasks/work left and it's the user who wrongly correlates this with "time left" in many cases. Note that the OP didn't complain about time, but about the percentage not going from 0% to 100% for example.
Yeah, you might be right about that. Still, that's not using a progress bar correctly if it's measuring multiple tasks — they should be measured individually, with spinners or a segmented progress bar.
The Novell client used to finish installing at about 103%
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.
I'd thought of making a progress bar library that you'd configure with information like: - author_uuid: 0xdeadbeef - download_size: 10GB, domain: example.com - file_write_size: 10GB - cpu_time_estimate: 8s - download_size: 100MB, domain: othersite.com - file_write_size: 200MB # after decompression - cpu_time_estimate: 30s and let it learn over time. My computer can figure out how fast it can download from example.com…
Earlier quoted context omitted.
>This seems a little funny to me, since the purpose of the spinner is so that you know the computer isn't caught in a loop — it's "busy". It's true, though, that the computer could still be stuck even though it updates the spinner. This is a hard problem to solve. The problem that people might assume the computer is stuck in a loop or at any rate that the animation is not going to stop is related to spinner animation…
That's because spinners used to show that the main thread was still responsive, but these days are used in different contexts where this isn't really something that it applies to anymore.
When progress bars are not useful it is because the underlying problem is hard to extrapolate faithfully. If you are doing just a few tasks where each one takes a significant different time to execute, it will be hard to estimate. More often than not, they work fine, IMO. When they don't, it is because for that particular problem it is genuinely hard to do. It isn't programmer's laziness, I think, in most cases.
Most users don't understand that making an accurate progress bar is incredibly hard, for most tasks. Is not very intuitive, but once you start looking in to it you realize that almost nothing in a computer is deterministic. Task switching, cashes, file system buffers, disk fragmentation, variable clock frequencies, and loads of other factors, make the speed of a computer very hard to estimate. I do favor progress bar…