Progress bars still lie(web.eecs.utk.edu) |
Progress bars still lie(web.eecs.utk.edu) |
The Novell client used to finish installing at about 103%
We have a kettle at work that shows a two-digit temperature in celcius (100=boiling). When you ask it to bring 94+ degree water to 100, it slowly changes the number from 94 to 100 without turning the element on.
Clearly enough people prefer to be lied to.
Where will it end...
like the "75% max" example from the post. Does it lie? yes. Can it be useful? very much, it is pretty easy to compensate.
- Doing anything with many smaller files will perform worse than fewer, larger files. Factor in a size/quantity multiplier/ratio on initial estimate. For APFS, I think the information needed should be available from init. For other file systems, this information should be gathered in a background process and feed the estimate as it accumulates.
- Revise the estimate more frequently, but not so frequently it produces pink noise. Apple’s progress bars notoriously get stuck for long periods, even hours. This isn’t just a bad user experience, it’s actually dangerous. Users frequently interrupt long running processes they perceive to be stalled, even if progress is ongoing but merely hard to observe. Swinging too far in the other direction at least gives an indication that something is happening, but the values become meaningless (I don’t know if this is still the case on Windows but I distinctly remember laughing uncontrollably watching estimates rapidly vacillate between seconds and hours, while overall progress appeared to have a steady pace).
- Revise the estimate based on expectations versus reality. As in, if your predetermined formula says 1000 small file operations take 15 seconds, but a comparable workload takes 30... and vice versa for large file operations... measure that! You don’t need machine learning for this, just a sufficiently proportionate time window to do some basic arithmetic.
- Provide additional observable feedback when these adjustments take place, and when there’s nothing to report other than something is taking a long time to generate more meaningful feedback. This doesn’t have to be ugly or noisy, it can be as simple as expanding the progress bar or messaging that progress is really ongoing even if you have no more information to report.
- Give us nerds a log! Please for the love of all that’s good in the world, let us see the sausage go through the grinder, even if we need to know a magic incantation to conjure it. And supplement it with a heartbeat message during long runs so we also don’t fall prey to dangerously assuming the process has stalled.
- I know Apple is notoriously minimalist in its UX style (most of the time), but maybe more information is sometimes actually less. As an example, major OS updates often quietly include multiple stages like firmware updates that require a reboot or temporarily disabling the display. These can be very alarming to users who don’t know what happened! Again, not just bad UX, it can be misleading and users may assume they’ve experienced failure or even an update loop that won’t terminate. A small amount of communication to set expectations could go a long way to alleviate that. A simple list of the overall steps and a bit of warning before a major visual disruption to observable progress would significantly reduce the chaotic list of assumptions users might be imagining.
- Maybe these updates are just too big, and doing too much at once. I mean, I understand that a major version update is going to have bigger subsystem impact, but maybe some of the ancillary stuff can be deferred. As an example, a major version update could get enough of the underlying update in place to get the machine in a usable state, then prioritize user land updates based on demand and run the rest in a background process.
- If you just don’t know, maybe it’s better to just be more vague. Apple popularized the spinner where progress is indeterminate. Use it as a last resort!
More than hard, it is undecidable.
Progress bars are much better than spinners in many cases though, even if they lie, at least I get a rough estimation how long something is expected to take, and if it gets stuck.
If instead I can see something like...step 1/5, downloading package... that's far more meaningful, at least to me.
This is separate from time estimations, though. The progress may not run at a uniform speed, which is OK; just mention the percentage of progress if known, or a plain number if not. If there are multiple steps, display the progress for each individual step, and document what the steps are.
In a few cases (e.g. hashcash), the progress is not known, so just a "spinning" indicator (or displaying a plain (non-percentage) number which just increases while it is executing) might be used instead.
On connection it shows the last image sent by the camera, and a progress percent. The progress is really a connection timeout, and you can't be sure it connected or not until it reaches 98% and fails.
How about an indeterminate progress bar, but it has a button you can click that tells you the app hasn't died? :)
- 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 based on previous transfers. It can figure out how fast my hard drive is based on previous writes. It can figure out how fast its CPU compared to that particular vendor's test system based on previous runs. And if a company like Apple were to deploy this, they could pre-populate the database with very accurate guesses for file write speeds and CPU seconds.
If you had that information, the progress bar could have a pretty solid idea of how long the total progress would take.
* Tells people what stage we're on. "Downloading", "Installing", "Cleaning Up".
* Can make bar for each step or guesstimated across all steps, either is ok.
* Do not show sub-step time estimates. If you show time estimates at all, do it for the whole process.
* Bar represents definite knowable progress: files moved, MB downloaded, etc. It thus never moves backward. If the stage has nothing knowable, make the bar full-width and stripey as a spinner equivalent.
* Able to open a verbose view that shows log stuff: actual numbers and filenames. The MacOS installer has this and good lord it was important when the MacTeX bug hit
Does this surface information that unempowered users don't need? Sure. Their eyes will just glaze over and it'll be fine.
While working on a popular AAA franchise at EA, we had loading screens which were sometimes really long and depended mainly on your connection speed. We estimated a worst case time for clients with slow Internet but not slow enough to time out and then made the progress bar driven by a timer from zero to this time.
Even knowing how it worked I repeatedly found myself intently staring at the loading bar.
We joked that it must take a lot of work computing those VT-100 characters and went back about our business, and I swear to god, an hour later the exact same thing happened in a completely different piece of software.
I can't believe the art of software development has regressed so much in my lifetime.
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 HD”.) I’ve never seen it go back down, only ever upwards.
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).
.progress {
height: 100px;
background-color: red;
animation-name: example;
animation-duration: 10000s;
}
@keyframes example {
0% {width: 0%;}
0.1% {width: 50%;}
2% {width: 90%;}
100% {width: 99%;}
}It's comforting to see something is happening and things are moving forward.
During the task, hook me up in another thread with a ML chat buddy that baits me with political statements chosen to maximize my outrage. Since my attention has been fully captured for the duration-- regardless of the length-- the programmer doesn't have to waste any time trying to measure how long the task takes to complete.
If your progress bar implementation is getting things wrong, you can probably just replace it with a loading spinner and call it a day. That's a vastly easier solution than making the progress bar accurate.
Any longer than that, reassurance comes from visual previews of what's happening, see vray preview windows for renders. Basically that feeling of shit getting done from watching laser and 3D printers do their thing.
The options are: 1) don't show progress. Show a marquee, as to not lie. This is terrible. Please don't do this. 2) Show two phases. E.g. the first phase progress runs slowly from 0-100 and the second one runs instantly from 0-100. 3) Guess better. Such as do it adaptively. The expected time for phase N is estimated from data (e.g. last time for commit phase, or from a bandwidth estimate from last upload times the file size). 5) Add a minimum phase time so that instantaneous completion takes e.g. 50ms, so people get time to see the completion at 100%. 4) Do nothing. No one expects progress bars to run linearly.
There are so many good options that are better than "don't show progress, only show activity". Even the do nothing/status quo alternative is much better than no progress bar.
What does he expect? That larger files go over 100%? Who knows how the progress bar is calculating, but the assumption that every file shouldn't finish at the same percentage just seems very odd.
There's an obvious explanation for why they finish at 75% though - to export a photo it presumably has to download it, and then do "something else" (maybe format conversion?). Measuring download progress is easy, but presumably the "something else" was more difficult to measure the progress on. Most libraries don't give progress feedback for most operations.
So the developer just thought "screw it, we'll allow 25% of the time for that processing". Based on the video they were wildly off but accurate progress bars are really low priority for a reason.
Will it able to predict if my internet connection going up or down in next few seconds of starting a new download.
I think the current progress bar represent the task progress not the estimated time left and the author is looking for something that shows actual time left.
Users just want to know it is working.
Users understand that 0-20 might take longer than 20-40
A while ago we put in a lot of engineering effort to build a good progress system for a heavy, multi-step background task to show to our users, and the overwhelming feedback was - "it always gets stuck on a certain percent", "it is too slow" and "it is unreliable". After feedback from design we hard-coded it to a steadily increasing bar regardless of actual progress, and the complaints all stopped immediately.
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.
If you instead just show a description of the current task, users will want to know how many tasks are left. if you tell them how many are left, they will revert to thinking of it as an overall percentage.
i'm a fan of "checklists" that get ticked off as the process progresses; possibly with progress bars for specific tasks, if they have a straightforward way of measuring that (like % downloaded). but i almost never include an overall progress bar for a multi-step process. it keeps the user's focus on the current task, while still providing some information about what's to come.
So when it Netflix is up, it slowly climbs 1-5% then rockets to 100% and plays.
When it's slow, sometimes it goes to 15%, then rockets up.
When it's down, it reaches 25% after 12.5s or whatever it is, then sits there forever/shows an error message.
Years later I worked on a popular AAA franchise and we had replace our loading screen spinner with a progress bar due to console requirements. We simply estimated a worst case scenario and made the bar driven by a timer from zero to this number, smoothly speeding towards 100 when loading was done. People kept complaining that something felt off and it didn't seem reliable.
Are you talking about progress bars, that go steadily up to 99 or 100% and then stay there, until the actual progress is done? They can cause big frustration, too ...
This seems like a surefire way to end up with a progress bar at 8675309%, or a progress bar that gets to 100% and then sits there waiting for reality to catch up. And I say this from experience, having seen both of these failure cases numerous times in the wild.
If users are frequently reporting that the application's getting stuck at a particular percent, then - to me at least - that's valuable information for whether I should consider doing some optimization to speed up whatever step in the process corresponds with that progress percentage, or to break down that step further into smaller steps to keep things moving, or both.
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). In the case of say "bytes currently downloaded" this becomes essentially a continuous stream of steps (which is a good thing!).
First and foremost what this communicates to users is that the system is doing something useful. This is what frustrates me about spinners. They are functionally indistinguishable from a frozen system, to the point now that users synonymously identify an indefinitely spinning spinner with a frozen system. And progress bars that asymptotically approach completion even when the program is frozen have trained users to be similarly suspicious of progress bars.
Secondarily it offers the same vague assurances as a progress bar about approximately how much time is left. If you see 250 GB out of 500 GB downloaded you'll assume that you're half-way there, similarly if you see 250 steps out of 500 completed. Especially in the case of the latter, there's no guarantee that the total elapsed time is already 50% over, but that's true of progress bars as well.
Finally, if something goes wrong, there's usually a useful error message that can be shown since there's the context of all the previous steps that led up to this error.
I ended up using this strategy recently because I wanted to convey that my app was "doing work on your behalf", so I tossed in a super quick progress bar like TurboTax does and then did a slick transition animation to show the results. It's "unnecessary" in that I could've just showed you the results, but I really wanted to convey that there was a sort of cause-and-effect in the system. Without that little bit of animation, it felt like that would've been lost.
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 left having no idea if something's failed, or what to do if I know it's failed.
Now I'm not suggesting that this is good as-is for non-technical users, but it feels wrong-headed keep iterating on a solution everyone hates (progress bars), rather than trying to adapt a solution that (if other people feel the same as me) is quite well-liked in its domain.
You see a sort of adaptation in some progress bars with the "Show details" button, but that generally sanitised variant, with one line per task and no commentary (and often, for some reason, no task count) feels like it misses all the good parts of what it's emulating.
Edit: typos
I'd love to hear an HN reader who is brave enough to own up to implementing one of these explain the rationale behind them.
Best (honest) progress bars are still those of software package managers, because they simply update on a percentage, have no step/idle animations and always show where you are exactly.
Surprisingly, MS has recently done a great job with explorer's copy progress by showing a graph. Filesystems and disks have nonlinear performance and rather than trying to extrapolate, they allow you to see when caches exhaust and the speed falls to its final value. When it stops or starts to degrade, you see that too and may try to pause a competing/interfering process.
After various progressbars on different projects my approach is this:
- Have an array of tasks
- Have a % progressbar
- Each task adds (100/total_tasks)% once completed regardless of how fast it is
Now comes the fun part. There is this single task that takes up the majority of the time amd your progressbar is stuck at 56% percent for too much time compared to the other tasks. You don't have feedback as a user. Is it stuck? Is it still going on?
Now is the time to optimize for use experience!
Why is this task taking so long? Are you loading a huge asset? Break it up, compress it, optimoze it. Are you doing something CPU intensive? Break up your computation over distinct tasks.
This attitude has led me to implement better technological solutions as well as user experiences
It's often an illusion and showing too much how the sausage is made makes the user start asking questions about what's happening behind the scenes.
That said, a long task that is prone to failure due to external factors should definitely be conveyed in the progress bar. If a bad network connection is affecting a process from finishing, you obviously want the user to know that so they don't blame the software for being slow. :)
What does the progress mean? Is it the fraction of work done or an indication of time left?
Progress bars don't necessarily lie - they simply omit useful information. Estimating progress is hard if there's variables involved that are outside the application's control, e.g. network speed or task switches initiated by the OS.
Task-based progress bars suffer from being "jumpy" and terribly inconsistent, because some tasks take longer than others and the progress indication doesn't allow to estimate the remaining the time.
Time-based progress bars are bad, because they are dynamic by nature of factors mentioned earlier, so ETA might suddenly jump from 1:23 min to 58:07 min or just as bad from 15 minutes to 3 seconds.
This is also the reason why "this is how long it took for other users" is not a great solution either: if your particular circumstances (network speed, server load, ...) are vastly different at the time, this would solve nothing and result in the same complaints.
Progress bars are just an estimation and a mixture of tasks left, ETA and a generic activity indicator ("the app didn't crash and still makes progress") might be more informative.
EDIT: for short tasks (e.g. 20 seconds or less), a simple progression of messages like "working on it", "just a moment", "almost there", "finished" might be the best option.
A progress bar should measure exactly one dimension, where a total is known, and a label should show what the dimension is. Usually progress bars implicitly measure "time left", but the total isn't known in that case, so progress bars are inapproprate.
For most "loading" scenarios, a spinner is a more appropriate element.
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.
I think it's more sensible to find a UI language that can seamlessly incorporate a progress bar and a dumb spinner with some note on what's going on. Which one is shown/used will depend on the task that is being loaded. Different words for different things.
I like MS Windows 10 "file transfer over a network" progress bar (though the pause button seems iffy...). The "hopes and dreams" simple progress bar is labelled factually and can't be accused of lying. And more information is available upon request and is simply factual.
A lot of work for a simple case of transferring files though. Much easier to default to the boring progress bar and some 0% to 100% assumptions to abstract things away so the "dumb user" doesn't have to worry... (NOTE: I hate the seemingly persistent concept of "dumb user" that so many people have.)
If your users have worries about your application performance to the extent that you are required to address them, then 90% of the time a dumb progress bar isn't the full answer. It may be an answer that makes management or user testing groups happy, but perpetuates the lie the article addresses.
Edit: snipped crap and added caveat note.
Progress bars work worst when they are combining extremely disparate steps. You might need to run 10 functions, but if one takes 0.1 seconds and one takes 45 seconds, it makes little sense for each step to be counted the same atomically or to present each as 10% of a progress bar.
The absolute worst case scenario is when you depend on an external resource about which availability is unknown but highly variable.
1) Apple software updates or OS installs usually never have the bar progress past 30% or so. I don't think they lie, so much as 100% is actually at 40%.
2) Windows installation. Copying Windows files jumps straight to 100%, Expanding Windows files is the only one that provides meaningful indication, installing features and installing updates happen instantly.
Then, it goes into a period of indeterminate loading spinner after a reboot.
These days, where possible (i.e. on VM, or if I'm in the OS already) I just use iStat menus or other monitoring software to check if things are using the processor by checking the CPU usage, CPU power consumption, disk read/write, and network activity. If something's happening, I let it sit. If not, the process needs to be restarted.
Basically: tell me how long it took other people.
A somewhat related approach is used by build servers showing a progress bar of the current build base on how long the previous build(s) of the same project took.
as an analogy, I really like RAII-based cancellation for futures in rust. dropping a future means the caller is no longer interested, and the sane behavior of cancelling all of the subfutures is the default. this seems simple at first, but dropping a single future may end up cancelling operations on other threads, freeing buffers, and so on, and the programmer profitably stumbles into the correct behavior.
so, it'd be nice for having a similarly composable abstraction for reporting progress in an asynchronous system. `Control.Monad.Progress`[1] just uses a float in [0, 1] to represent progress, and `NSProgress`[2] has a bit more going on but still requires the programmer to manually partition a parent task into its subtasks.
I'm not sure this is altogether possible, but I could imagine 1) a library for expressing the ground truth of where parts of a system are and then 2) a heuristic based layer above for turning snapshots of the system into time estimates and percentages working well.
[1] https://hackage.haskell.org/package/progress-reporting-1.0.0...
[2] https://developer.apple.com/documentation/foundation/progres...
- We forgot to embed the JS that does the AJAX loading
- The JS has an error before it even makes a request
- The src URL of a script doesn't exist
- Some cross-domain issue prevents a script loading
- The user agent doesn't support JS
I accept that it can be tricky to remove a spinner correctly in the face of certain error conditions, but it's trivial to avoid showing it until it's meaningful. So please: only insert/reveal spinners programatically, just before the associated request is made.
In fact, this same logic applies to all UI elements that are only meaningful thanks to JS (e.g. buttons that require an event handler, rather than submitting a form); such things should be inserted/revealed programatically using JS, not visible in the initial response HTML, so we don't end up clicking over and over on a button that's useless, etc.
I get that many Web devs these days don't care about progressive enhancement, and like to assume all users have HTML5+CSS+JS+etc. but even that assumption doesn't excuse spinners that lie when a connection fails, or a server is misconfigured, or a third-party moves some assets, etc.
https://twitter.com/breckyunits/status/1331381360397672448?s...
And you could break it down recursively by task as well.
- A progress bar should not measure multiple tasks, unless each task is of the same type (e.g. converting a batch of files, _not_ system booting)
- A progress bar should not measure "time left" unless it is literally tied to the value of a timer (i.e. _not_ "time left to download big file")
- A progress bar does not show "busy state" — a spinner does that. A progress bar can stop if e.g. it measures bytes of a file downloaded and the network connection drops; a spinner will still spin.
- A progress bar should include a label to explicitly state what it is measuring (otherwise users will assume it means "time left")
People like to see progress bars because they want to know "progress is being made", but a progress bar is not always appropriate, depending on the situation. Instead, consider using:
- Spinners show activity is happening. Use when there isn't a single metric to report, or the "bounds" of the metric aren't known.
- A checklist can show different tasks completed in sequence. Can be combined with a spinner on the "current" task
- A segmented progress bar can replace a checklist when each task could be represented by a progress bar
Just my opinions, I guess, and obviously we don't live in the world where the above is applied, but it feels good to have it sorted in my own head. Curious what others think of this scheme.
Next you'll be asking programmers to estimate how long they going to take to do something...!
;-)
-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
If we could be sure the computer wouldn't get stuck (which is just a bug), then progress bars and spinners would be fine. If the task is as granular as you suggest, progress bars would be a great visual indicator, much better than text.
But since computers do get stuck, additional indicators should help with that. A spinner is supposed to show that a process isn't stuck, but those are fallible too. A textual representation ("bytes currently downloaded") sounds like a great addition to a progress bar. I've seen this a lot on linux distro installers, where you can click "details" below the progress bar to see the console output.
They need to be trustworthy. For that, they need to be wired directly into the process doing the work. So no spinner gifs that are animated by the browser/renderer, and can spin forever even if your application dies. It needs to be something where any visual change is directly related to the operations you're monitoring.
That's why a list with textual descriptions of step is a great idea - it's literally too much work to implement it in a way other than the actual completion of a step displaying/ticking off a corresponding label. So seeing that, I'd know the software isn't lying to me.
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.
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...
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
Doing the scanning and the processing at the same time may be faster. It should be clear though when the total has been established and when it isn't yet.
For long builds I have stopped watching build logs live altogether and append `; tput bel` to the command to get audible feedback at the end.
For graphical applications, especially on mobile, I wish progress bars got out of the way more. Users ought to be able to continue using an app while a task occurs in a separate thread, and whose progress bar doesn't take up the entire visual field. Many apps, especially on iOS, seem to still be guilty of this.
[0] The creator shows it off here, to applause: https://youtu.be/XVIKScU7Uf4?t=420
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 becomes increasingly slow as it nears the end. I suspect the bar is programmed to never increase by more than half the remaining distance, or something like that.
After half an hour, I finally realized something had to be wrong, and I tried whitelisting figma.com in my proxy. The document loaded immediately.
If Figma hadn't lied to me with a fake progress bar, it would have saved so much time...
That's where "marquee" progress bars fit in. Those poor abominations that, like Sisyphus, progress without advancing, because a simple activity indicator wasn't user-friendly enough.
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.
Absolutely agree, but then, don't make it a percentage progress bar. Make it one of those "amount unknown" bars, or better yet, a spinner or game-like loading screen. Something with movement that tells me things are happening. Don't pretend to know "how done" it is if you don't know.
2.) Project Manager creates dev task "make action X fast"
3.) Too much work to actually make action X fast. Decides to make the user feel like it's going faster.
4.) Deploys fake progress bar to prod. No new tickets.
It's impossible to estimate total completion percentage when one part of the operation is CPU-bound, and another part is disk-bound.
(I haven't had to deal with network-bound operations, but I feel for those who do.)
Truth is probably possible, but more work than it's worth, when one part of the operation is O(n) and another part is O(m^2).
If the feature is a week late, it doesn't crash, the answers are right, and the operation completes in a reasonable amount of time, I'm moving on with my life.
Alternatively you could use multiple bars - one showing the number of distinct tasks to complete, and the other showing the estimated time progression of the current task. Ideally chuck an expandible debug log underneath it. You probably want to be implementing a debug log while developing to test the thing anyway, just leave it in there! A lot of installers use this kind of progress bar and I've always found them to be the most user-friendly.
You could split up the overall progress into two parts, 50% of the bar each. The first part might take a while to finish and when you get to 50% you determine how much is left in the second half, and if it's quick, you immediately jump to 100%. On the other hand, if the second half takes really long, now you're sitting there waiting what seems like an eternity to do the second half.
With some clever design, you could have a smarter progress bar system where each task is weighted and adding it to the overall progress re-computes how long everything is, but now you have a scenario where the progress bar could shrink as you get more accurate about the work ahead.
If the time to complete a task is short enough, a lot of these tricks for more accuracy just aren't worth it, and often require fundamentally changing the architecture of your underlying processes, making it more work than it's worth. Hence, you end up with funny things like finishing at 75%. Though, to be fair, they should at least jump to 100% before finishing. I think that's a common bug that comes up, not letting the full bar show first before dismissing.
I mocked it up in Figma, I didn't display any numbers, only a cute lil line. Then built it with React Native, super easy and quick, it looked & felt great to me.
So for the actual estimate, what I did was store how long it took to run the task for my users, and then select the 95th percentile from actual runs to get an estimate. Then when they loaded the app, I would send over the estimates (along with their account info and what not). I figured if it ended sooner than what it was projecting, the user would be happy, or at least I was.
I used my own app, and kept tweaking it until it felt right, and it felt really good. YMMV chef's kiss
We needed a progress bar, but there was no way to estimate progress.
I do favor progress bars that say things like "you have downloaded 47% of file X", because its a statement of fact, not an estimation of future performance.
Abusing progress bars are not a good response to this, though. I would rather trust progress bars for what they are meant to show rather than as an indication of true activity. After all, you still can't tell whether the progress bar kept moving, but the process is stuck in a loop.
With multiple things wrapped into one, you often end up in situations where 0-99% (or whatever) might happen super fast but that last 1% takes ages, making the progress bar useless as a "something's happening" indicator.
Those old windows installers used two bars: the top one was basically a steps indicator (file N of M, for example) -- just like the single bar for multiple tasks. But the second bar was a per-file bar. So if step 99 took longer, you had a second bar showing you that steps/files progress.
It didn't take me long to realize that the progress bar measured bytes written to disk, but when it was seemingly "stuck", it was creating a lot of small files.
Instead of bytes written, what I really cared about is "how done are you?" and that would have been better represented by a function of both number of files created _and_ bytes written. I don't think the weighting of those two had to be very accurate to be a big improvement.
If there are multiple independent tasks, give me multiple independent indicators of their state. Multiple instances of the same class of task can of course be grouped, you don't need to list every file copy independently, but a file copy and an external dependency installer shouldn't be two stops on the same progress bar.
Not sure why exactly you put quotation marks there, but 400ms is incredibly slow, at least relative to human perception and what computers should be able to do. Consider what AAA games can render in 16ms.
My demo has unfortunately fallen to web bit rot and needs to be updated, but the code is here to explore: https://github.com/worldmaker/compradprog
name:search-termFor which a visualization exists internally, but every time someone decides to "fix" the progress bar problem they do a one-off analysis and only wire up the three biggest steps to the bar.
Found out about package conflict only after running apt from the terminal.
Given that as a standard, it's difficult for me to find more outrage for Turbotax misusing this already mendacious widget.
1: Some smarty pants is going to say that at least the percentage is directional and shifting Matrix glyphs are not. Unfortunately, even that isn't true-- UIs have a long history of multiple sequential progress bars with no indication how many there are in total-- see Office Space. So progress widgets have burned through user trust long ago-- even if I've experienced Windows 10 having a single percentage counter that persists across restarts, perhaps the next update will be the time they break that pattern.
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.
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 animations on websites. Since the spinner is not a function of the browser, but is instead something implemented in the individual site's code, then stopping the spinner needs to be also coded for and many sites neglect to write the code for "when error happens stop spinner and tell them that things went wrong".
So over time people exposed to negligent website spinners start to suspect any spinner that takes too long.
I suppose I understand wanting SOMETHING to show up, but could we PLEASE make it be the raw text first?
A blank page for 2 seconds is worse for the average user than a UI template instantly and 2.2 seconds of content filling.
This reminds me of a counterpoint to my top-level comment of how frustrating Apple’s progress bars are: way back in the early OS X days, they did user tests that showed people respond better to longer running progress disclosure than shorter running real progress. So they literally baked a delay into the OS X boot process that would make booting take longer but show a more predictable progress bar.
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.
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.
As with so many of the issues in web apps, its not even complex or hard to fix these issues. Its just no one cares enough to schedule time for it.
I know it’s unpopular in these parts but checked exceptions would make this impossible.
With a progress bar I don't know anything.
> If the users can see the detailed tasks, maybe they will be less ticked off by a jumpy progress bar.
This was back when my best computer had a 500 MHz CPU and 512 MB of RAM.
>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.
If so, it doesn't seem completely unreasonable to communicate in this way. (I agree it could be communicated better)
The system is not quite hung, but it's not doing great.
At the very least, there's no sense in which the page loading (or map route finding, etc) was farther along at t=2 than it was at t=1 when the connection was removed, so for Google to be telling me it's making progress in that situation is a transparent lie.
Unless the information they're trying to convey with the progress bar is simply that "time is passing", which I'm well aware of.
There's no reason to lie.
My point is that good UI is possible, there is even precedent for it, and that while we definitely need to do better perhaps with available APIs or tooling, that is not an excuse for the moral failing of lying to the user.
¹and I'd say that's even the mild case. A number of high-profile websites that encounter even edge cases — not even errors — just simply fail to render at all.
"Your task has started and is processing in the background where it can't be observed. Please wait."
[OK]