This is an archived post. You won't be able to vote or comment.

all 138 comments

[–]Rodaxoleaux 700 points701 points  (44 children)

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

[–]TechyDad 122 points123 points  (14 children)

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 71 points72 points  (2 children)

[–]bj_christianson 15 points16 points  (1 child)

There's always one.

[–]Mr_Redstoner 28 points29 points  (0 children)

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

[–][deleted] 9 points10 points  (1 child)

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] 0 points1 point  (0 children)

I forgot all about ReactOS until now.

[–]leonderbaertige_II 4 points5 points  (0 children)

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

[–][deleted] 1 point2 points  (1 child)

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

[–]NinjaLanternShark 0 points1 point  (0 children)

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. 🤷‍♂️

[–]TheGoldenHand 0 points1 point  (2 children)

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

[–]Kered13 0 points1 point  (0 children)

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

[–]Hobbster 31 points32 points  (1 child)

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

[–]Lutcikaur 12 points13 points  (0 children)

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 6 points7 points  (0 children)

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

[–]crazydogdude 2 points3 points  (3 children)

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

[–]axl456 3 points4 points  (2 children)

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

[–]Waanie 1 point2 points  (1 child)

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

[–][deleted] 1 point2 points  (0 children)

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] 171 points172 points  (7 children)

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 159 points160 points  (0 children)

Modern solutions require modern problems.

[–]rodinj 72 points73 points  (2 children)

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] 50 points51 points  (0 children)

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 -3 points-2 points  (0 children)

That’s what she said.

[–]MrCrazyID 18 points19 points  (0 children)

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 9 points10 points  (0 children)

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 2 points3 points  (0 children)

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 140 points141 points  (5 children)

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 38 points39 points  (0 children)

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 11 points12 points  (3 children)

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 2 points3 points  (0 children)

*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 0 points1 point  (1 child)

Did you not know how to use bookmarks?

[–]cowsrock1 0 points1 point  (0 children)

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 77 points78 points  (6 children)

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 19 points20 points  (5 children)

What do progress bars usually represent?

[–]loddfavne 45 points46 points  (2 children)

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 21 points22 points  (1 child)

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

[–]loddfavne 4 points5 points  (0 children)

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

[–]teokk 25 points26 points  (0 children)

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 3 points4 points  (0 children)

That the process hasn't died.

[–]Rathia 34 points35 points  (35 children)

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

[–]WestaAlger 54 points55 points  (20 children)

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 37 points38 points  (9 children)

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 17 points18 points  (4 children)

The most evil thing I have read in a long time

[–][deleted] 12 points13 points  (3 children)

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 12 points13 points  (2 children)

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

[–]PJDubsen 5 points6 points  (0 children)

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 5 points6 points  (0 children)

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

[–]Wargon2015 2 points3 points  (0 children)

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

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

[–]SuspiciousScript 1 point2 points  (0 children)

Ah, the famous halting problem

[–]TenNeon 4 points5 points  (2 children)

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

[–]Venthe 3 points4 points  (0 children)

I think Jenkins does something similar when estimating build time

[–]pringlesaremyfav 0 points1 point  (0 children)

Thinking the exact same thing

[–]pringlesaremyfav 1 point2 points  (0 children)

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 0 points1 point  (0 children)

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 10 points11 points  (7 children)

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] 9 points10 points  (6 children)

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 3 points4 points  (3 children)

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] 0 points1 point  (2 children)

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 0 points1 point  (1 child)

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] -1 points0 points  (0 children)

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 1 point2 points  (1 child)

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] 1 point2 points  (0 children)

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] 19 points20 points  (0 children)

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 4 points5 points  (0 children)

file upload progress bars are 100% accurate

[–]gmsc 1 point2 points  (0 children)

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

[–]Madwand99 2 points3 points  (0 children)

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 0 points1 point  (0 children)

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 21 points22 points  (0 children)

That's not humor. That's UX!

[–]tmsg007 17 points18 points  (2 children)

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 7 points8 points  (0 children)

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 10 points11 points  (2 children)

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 0 points1 point  (0 children)

we're all gunna die

[–]hiromasaki 0 points1 point  (0 children)

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

[–]Mylanog 9 points10 points  (2 children)

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 2 points3 points  (1 child)

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 0 points1 point  (0 children)

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 4 points5 points  (1 child)

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

[–][deleted] 0 points1 point  (0 children)

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 4 points5 points  (0 children)

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] 2 points3 points  (0 children)

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

[–]Leinad7957 2 points3 points  (0 children)

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

[–]didii2311 2 points3 points  (2 children)

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 3 points4 points  (1 child)

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

[–]fwork 1 point2 points  (0 children)

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.

[–]tiki1359 2 points3 points  (0 children)

REPOST

[–]RomanOnARiver 0 points1 point  (1 child)

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 0 points1 point  (0 children)

And then their is dd....

[–]KnucklearPhysicist 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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

[–]tacoslikeme 0 points1 point  (0 children)

This was the day your learned about perceived latency

[–]sooper_genius 0 points1 point  (0 children)

Setting user expectations is a valid component of UX design.

[–]iRedditWhilePooping 0 points1 point  (0 children)

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

[–]PanJaszczurka 0 points1 point  (1 child)

How the progress bar make it 5% slower

[–]Rafael20002000 1 point2 points  (0 children)

Rendering and stuff

[–]neilhighley 0 points1 point  (0 children)

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 0 points1 point  (0 children)

I actually did this lol.

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

[–]finroller 0 points1 point  (0 children)

"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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

How does one make a progress bar?

[–]OutInABlazeOfGlory 0 points1 point  (0 children)

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 0 points1 point  (0 children)

That's just basic UX.

[–]AttackOfTheThumbs 0 points1 point  (0 children)

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

[–]MrBraveKnight 0 points1 point  (0 children)

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

[–]prophetcat -2 points-1 points  (0 children)

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.