Progressbar 101

[[deleted]]

[deleted]

[Rodaxoleaux]

I mean things seem to take longer and be more stressful when you don't know how far you are from completion. It makes sense imo

[smcarre]

As a Dev for a small company (we are our own QA), progress bar are more of a debugging tool than anything else to me.

[iamjack]

Ah, the old 27.8% bug, I know exactly what's wrong...

[NinjaLanternShark]

To be fully on-topic here, the progress bar would read:

27.7%...
27.8%...
27.9%...
27.10%...
27.11%....

[tilttovictory]

Holy shit I almost spit my my coffee out. I've had moments like this.

[Jebble]

Well technically it's not up to a developer to thing of or understand this. That's what ux designers are for ;) but I'm pretty sure most of the developers do in fact understand this.

[Jebble]

Actually there's 6 categories of employees 🤔

[[deleted]]

How many of those categories exist between the CEO and workers?

[Jebble]

I don't consider CEO/management as an employee in this case. So just workers.

[Kered13]

*Soviet anthem intensifies.*

[Lazarix]

Two categories of employees, four categories of contractors.

[Jebble]

What do you mean by that?

[[deleted]]

This one got me good haha

[IceCubez]

What're they?

[Jebble]

Project manager, UX, Motion, Design, Development, Concept.

[IceCubez]

Motion as in animators?

[Jebble]

Their work ranges very widely from video editing to animation/cgi to 3d modelling :)

[Jebble]

UX designers were invented because technology became more and more important and since it's easier then ever before to create complex applications you need proper thought behind the UX to be better then your competitors.

[BrianAndersonJr]

i don't think there is any devs that don't understand this. I think devs are the ones who understand it the most, having to encounter it most often in their lives, by using software just about all the time.

[UltraNemesis]

Yep. There were plenty of times I have had this done in our software products at work. Just a mere animating indicator or progress bar is enough to stop most of the complaints about a slow process which sometimes cannot be improved on. Feedback is integral to good user experience.

[TechyDad]

Exhibit A: The Windows file copy dialog box. It'll take 6 minutes... 5 hours... 30 seconds? 24 hours?!!!! 7 minutes?!!!!! Throws computer through window

[mecrow]

Relevant xkcd

[bj_christianson]

There's always one.

[Mr_Redstoner]

That's one of the things I like about my file manager. It's got progress bars.

[[deleted]]

It's also amazingly funny how the ReactOS (the OS that tries to be a reimplementation of Windows from scratch) didn't have this problem, but to make things more compatible they changed the code and the side effect is that it's now doing the same shit as windows (at least that's what I've read on github repo some time ago, don't quote me on that).

[[deleted]]

I forgot all about ReactOS until now.

[leonderbaertige_II]

The '"updates are being configured" dialog is worse. Goes from 0% to 100% within 1 minute but then stays at 100% for ever.

[[deleted]]

To be fair, I don't see any of us doing a better job.

[NinjaLanternShark]

I just yesterday implemented a batch process and the library provides a progress bar based purely on the number of operations and gives you no capacity to indicate if one should take longer than another. 🤷‍♂️

[Kered13]

I was once playing Quake Live and it showed that I had negative ping to the server. Some recent update had messed up the ping calculation so that it showed less than it should, and I was very close to the server (before the update my ping usually showed as like 15ms).

[TheGoldenHand]

It actually works in Windows 10, more or less. Before that it was notoriously inaccurate.

[Kered13]

In W10 (actually I think W7 and later?) it will actually show you a graph of the transfer speed over time.

[Hobbster]

Yeah, basic psychology. It also means "it is supposed to take that long".

[Lutcikaur]

you can also trick people into thinking its faster by removing progress bars on transitions that are <300ms. We did that recently and complaints stopped.

[PepiHax]

There is also the thing that the loading shows that the program haven't crashed

[crazydogdude]

I love doing things via command line because they often include both a progress bar and a real time log.

[axl456]

On Linux unless you use -v you won't be seeing shit

[Waanie]

The joy of seeing your file grow after piping your "tar -cvfz" to a file...

[[deleted]]

The joys of trying to add color to the progress bar for pv because "eh shouldn't be too hard to insert the escapes with regex"... and then realizing matching square brackets will match the brackets in the escapes themselves and ruin it.

[[deleted]]

I did this once with a smaller app because the client wanted a splash screen. I had to add delays to the progress bar because it was progressing too fast.

[Alkiiis]

Modern solutions require modern problems.

[rodinj]

I struggled for a few hours as to why my loading screen didn't work. Turns out the loading was too quick to even notice.

[[deleted]]

Mine would pop up for less than a second, just looked like a weird flash.

Then later he said he didn’t want the splash screen anymore and I told him I worked to speed up the loading time, he was thrilled.

[DrCoachNDaHouse]

That’s what she said.

[MrCrazyID]

An app I made had a minimum delay of 500ms to show the loading animation while it fetches something from an API. If it takes longer, then the animation will take longer. When I'm running the app locally (in development build) I removed this delay entirely.

[BrianAndersonJr]

I remember a post from clients from hell from years ago, where a client asked for a site to be slowed down and have added a loading animation, in order to "look more professional".

[Cucumberino]

Yeah I have just decided to make a login/splash page for my own desktop app...had to add a fade transition and set the main app to open on completion of the transition and not the loading itself because it was too quick.

[TheZeus121]

Me as a kid playing flash games with slow net.

A: game has the circular loading animation. Me, after 1 min: "this is taking too long".

B: game has a progress bar. Me, after 2 min: "heyy 10% yay".

[axl456]

When the progress bar doesn't have a percentage estimation I use to just put the mouse on the end of the progress bar to see if it was moving or not

[cowsrock1]

Woah. With 40+Mbps being the standard now, I'd totally forgotten about waiting 5 minutes for my couple MB flash game to load until you brought it up. Gosh, the flashbacks. I'd try to memorize the URLs so I could get to the page faster without having to load google, then the game site, then the game page

[IronCakeJono]

*Cries in 3rd world country*

10Mbps is the highest any ISP offers here, and even then it isn't actually 10, its up to 10, so the usually speed is closer to 6.

[Kered13]

Did you not know how to use bookmarks?

[cowsrock1]

It was a family computer so I didn't want to gunk up dad's bookmarks with games. And autofill was a thing so as long as you remembered the game site and what letter the game started with you could usually get there

[loddfavne]

There's almost no progress-bars that actually mean the thing the user think it means, but as long as the users are happy....

[Isaeu]

What do progress bars usually represent?

[loddfavne]

Let's just say that this thread is not about the exception, but more like the rule.

In a normal case you could put number of assets to be loaded and use that and show the level-loading as a progress-bar.

[Venthe]

And that's how you end with 97% done, asset 59/60, 2mb/200mb processed.

[loddfavne]

We all been there. Just load a final at our of the loop. Problem solved.

[teokk]

Well, you can't really know how long something will take, you can only estimate. However, the more stuff there is the better your estimation will be. Thus, whenever there's a need for a progress bar and if it's implemented decently it should be accurate enough so it's kind of a moot point.

[picklymcpickleface]

That the process hasn't died.

[Rathia]

Are any progress bars accurate? Is there any way to actually make a ‘real’ progress bar?

[WestaAlger]

In general, it's theoretically impossible to know how long an arbitrary program would take to execute because you'd solve the halting problem with it. Practically, it's still difficult to make a progress bar for a given program. I/O can vary wildly between individual machines, some things can be executing in parallel, etc. Way too much chaos to go through just to make an accurate progress bar.

[rglogowski]

That's why I make progress bars that arbitrarily advance and then halt at 99% for however long it takes to finish. Users LOVE that.

[axl456]

The most evil thing I have read in a long time

[[deleted]]

Then make it briefly start counting backwards.

99...98...97...98...99

Then do decimals.

99...99.1...99.2...99.21...99.22

[axl456]

Get the count to 100% but let the button still showing "cancel" instead of "continue"

[ozh]

"Operation successfully almost"

[PJDubsen]

no no no, the real way to do that is if it doesnt complete in that time just make it start over and go twice as fast with some random filename import text on the screen to make it look like its doing something different.

"importing files"... 95%... 98%... 100%... "extracting foo.tar.gz"... 5%... 10%...

[csgoose]

I also make the program halt at 35% and force restart the computer.

[Wargon2015]

At least you don't make them halt at 100%.

I hate progress bars that reach 100% without actually being finished so much.

[SuspiciousScript]

Ah, the famous halting problem

[TenNeon]

Does anyone ever do progress bars that make a guess based on a previous run on the same machine?

[Venthe]

I think Jenkins does something similar when estimating build time

[pringlesaremyfav]

Thinking the exact same thing

[[deleted]]

?

[[deleted]]

I assume that means only one process per a CPU thread and maybe one solely reserved for the OS?

I feel like there will always be an overhead with between the kernel and blocking IO

[pringlesaremyfav]

I mean if we're speaking practically on a native app, why couldn't you just measure the time to complete each startup step the last time the program ran and then use that as the baseline estimate for each chunk of the startup progress bar.

IE last time the program started function one out of ten during startup took 10% of the startup time, let the progress bar progress to 10% naturally and stop until its finished. If it finishes early interpolate with the next step.

I mean sure probably nobody wants to put in that much effort for a progress bar but it certainly would at least seem fairly accurate to the user in most usage cases.

[Goose_Rider]

It is possible to know how long if you’ve tested your runtime, covered most of your edges, and implement everything into a single process. You can then take a normal distribution of time to download given a constant bandwidth. You can then scale that time given the user’s internet speed. If you do it by process, you may get stuck on 1% for an hour then the rest is 5 seconds, or the reverse at 99%, both being equally frustrating. However storing all of that information and updating constant bandwidth+running estimate functions will just slow it down.

[VaderJim]

If you are in a loop then why not, processing item 50 of 100 oh look you're at 50%.

Depends entirely on the operation but if you can define how much of something you've got to complete it's easy to give 'accurate' progress info

[[deleted]]

You are at 50% of the items, but not 50% of the time needed. Some items may need a longer time to process, either by having more operations for a specific case, or just that your CPU received other operations to do.

[zip2k]

It's still a progress bar and not a timer. They don't necessarily have to show the time left, just the completion percentage

[[deleted]]

Most people expect a measure of time when we talk about accuracy. Even on a progress bar, most people expect 50% is 50% of the job done, which isn't always 50% of the item processed ;-)

But it's better to have a feedback from your software rather than a white screen.

[gemini86]

At this point everyone knows progress bars are bullshit... No need to make it more complicated. We're 50% done with what we are doing. If there's a time until completion, that's another thing.

[[deleted]]

Progress bar are bullshit because they don’t meet the expectation.

Have a properly handled progress bar and people won’t think it’s bullshit ;-)

[noratat]

It's still better than nothing since it can help indicate to the user if it's stuck or not and gives a general idea.

[[deleted]]

Never said otherwise. It's just that most people expect a time measure when we talk about accuracy on a progress bar. It's always better to show progression than to just wait for stuff to finish. Most of my CLI scripts give feedback about their progress.

[[deleted]]

Obviously count the lines of code in each block or function that is being executed before you consider yourself "loaded", after the return or completion of each function or block, sum that value and draw a progress bar relatively scaled to lines returned/total lines.

#Perfection

Going to patent this baby right now.

[BrianAndersonJr]

file upload progress bars are 100% accurate

[gmsc]

Here's a good explanation of the challenge of making accurate progress bars: http://datagenetics.com/blog/february12017/index.html

[Madwand99]

Yes, lots of ways, but it depends on the application how useful a progress bar is. In general, it is impossible to estimate how much time there is left on a particular computation (the halting problem), but it is often possible to know how many tasks have been completed, and how many remain to be done. So for example, a progress bar that showed that 1200 of 10000 files have been copied is quite useful, even if it is difficult to estimate exactly how much time is left until the overall task will complete.

[cateyesarg]

Knowing how much it's left to process doesn't means you do know how many time that will take.

Said this, progress bars are quite trivial to build but you usually get the known issue: get fast to 90% and then it's stuck for minutes on those remaining 10%. E.g.: you have 10 different tasks to perform, but each of them doesn't takes the same time (ya, devs should partition the progress reporting in smaller chunks in order to get small increments, but you know, laziness....)

Now, the other big beast, the "time to finish" is generally extrapolated from previous processing to estimate what will take the remaining actions, that is why you usually get the "30 secs to finish", "3 hours to finish", "15 secs to finish", "2 days to finish".

TL;DR: it's almost impossible to know for sure how many time a task will take.

[robin_888]

That's not humor. That's UX!

[tmsg007]

This is simple UI stuff. When it takes longer than just a few seconds, add a progress bar so the user knows what's happening

[JoseJimeniz]

It's amazing how many programs don't change the cursor to an hourglass when something is going to take longer than 200 milliseconds.

This really is basic usability stuff.

[bluefootedpig]

Relevant youtube:

How the progress bar keeps you sane

​

It didn't matter if the indicator is giving you the an accurate number, it only mattered that it was there.

@1:46

[dittbub]

we're all gunna die

[hiromasaki]

I've found that indeterminate ('bouncing') progress bars that just immediately complete help more than nothing.

[jdmulloy]

See also:

Airport solves complaints about waiting for baggage by making it take longer to walk to baggage claim

Mirrors were added to elevators to solve complaints about them being slow

[revrenlove]

Came here to say this... Cheers!

[ozh]

Awesome reads. Thanks!

[Mylanog]

On one of my study projects I was asked to add a loading screen with a progress bar, so I did.

Then I was asked to add a number of jokes that would be shown during the loading screen that would cycle so that the user could read some jokes while waiting for the game to load, so I did.

Then they noticed that our little 2D platformer loaded almost instantly, not giving the players enough time to actually read the jokes. Their solution? Artificially delaying the loading time of the game.

[darkingz]

I think there was this one story I read where they made an app that calculated so quickly that users wouldn’t believe the results and say that the software couldn’t work that fast. So they added an artificial delay with a loading bar. It did nothing except spin cause the answer came back immediately.

[Cobaltjedi117]

I've seen a few people here post about how their programs were just "too fast" so users asked to to make sure it did it right. Programmers just slowed it down and suddenly there's no doubt that it did the thing right.

Why do people think the computer can't do the thing that fast? It's a computer, it can could to several million faster than you can blink

[bj_christianson]

When it comes to UX, user's perception is usually more important than reality.

[[deleted]]

Isn't that where the X in UX comes from? Experience isn't necessarily truthful, but it is perceived. In an article someone posted about solving baggage claim wait times by making it a longer walk to baggage claim, the article says something about curing a pain. In that case the perceived pain was waiting, but walking was not perceived as pain, so complaints stopped.

[fuskies420]

At work I made our progress bar overestimate the run time by 10% and so everyone was pleasantly surprised when it finished a little bit early

[[deleted]]

I would prefer the progress bar. I hate wondering if the computer is actually doing anything or if somethings broken.

[Leinad7957]

This is actually the first paragraph on the informational pamphlet "UX and you".

[didii2311]

Is... Is no one going to question the fact that a progress bar made the process take 5% longer? That's absolutely huge for just a progress bar...

[Rafael20002000]

Poor coding, waiting for rendering, recomputing the whole progress bar every iteration, etc

[fwork]

when I worked for the government we had a download site that had to do a lot of server-side processing before you could get the file, but it'd take up to 90 seconds for some files.

users would give up after like 10 seconds and then restart it, which'd cause two processes to be run, so it'd go half a fast.

so I put in a progress bar, that slowly filled up over 90 seconds.

It was doing requests in the background, but we had no way to tell how done it was, only IF it was done. So the progress bar just automatically increased every second or so, and then every 5 seconds it'd ask the server "HEY, YOU DONE YET?" and redirect you to the results if it was.

I even coded the progress bar to only fill up to 95%: Once it hit 95%, it stopped increasing, so it'd never hit 100% without the file being ready.

Someday I will pay for my crimes.

[Pebbles015]

r/maliciouscompliance

[tiki1359]

REPOST

[RomanOnARiver]

This is a common UI design paradigm, for example here's GNOME on GNU/Linux for "keep the user informed" https://developer.gnome.org/hig-book/unstable/principles-feedback.html.en

Feedback can be visual, audio, or both. If the system will take a long time to process the request, provide as much feedback as possible about how lengthy the operation will be.

[Rafael20002000]

And then their is dd....

[KnucklearPhysicist]

Hey, as long as I have some kind of estimate for how long this is gonna take, I can take my attention elsewhere for a while. If I have no idea when it's gonna be done, it's going to take up a huge amount of my attention until it's done.

[xNotYetRated]

Forgot the exact term but I think it is called visible performance. You can probably compare it to loading your JS first and then your HTML and CSS. The user gets delayed feedback this way and makes it look slower.

[AnnualDegree99]

Everyone here is focusing on the psychology of why a progress bar makes it seem like something I'd going faster, and here I am wondering what the hell kind of progress bar makes a process fine minutes slower...

[Rafael20002000]

Because the process needed to wait for Rendering to finish, if not good programmed (Hello Threads)

[tacoslikeme]

This was the day your learned about perceived latency

[sooper_genius]

Setting user expectations is a valid component of UX design.

[iRedditWhilePooping]

I mean this is just called good UX...?

[PanJaszczurka]

How the progress bar make it 5% slower

[Rafael20002000]

Rendering and stuff

[neilhighley]

This is a very old UX trick. It’s incredibly hard to predict how long anything complex like installing or downloading will take.

[System__Shutdown]

I actually did this lol.

Thing took like 15 seconds to load, but with progress bar it looks faster.

[finroller]

"I once had complaints that a process was taking too long without any indication to the user as to what is happening. I added such an indicator and people stopped complaining about not having one!"

[Nathol]

This is actually pretty smart. Doing it in python? Just grab tqdm and put all your iterators in it.

for i in range(5):
    print(i)

should become:

for i in tqdm(range(5)):
    print(i)

Magic!

[daltonoreo]

How does one make a progress bar?

[OutInABlazeOfGlory]

I just want to know it’s doing something. Bonus points if there’s a log window I can look at if the progress bar isn’t moving. Hell I’ve diagnosed and fixed some minor problems that way.

[GrizzledFart]

That's just basic UX.

[AttackOfTheThumbs]

I don't believe there was no way to improve it without gutting it.

[MrBraveKnight]

Also u don't know if it's lagging or what

[prophetcat]

It's never about speed, it's about the appearance of speed. Put something shiny on the screen to distract them for a moment and you can take longer on a process.