Forgot your password?
typodupeerror
Programming

Ask Slashdot: Why Is It So Hard To Make An Accurate Progress Bar? 736

Posted by Soulskill
from the this-post-is-98%-complete dept.
hyperorbiter writes "How come after 25 years in the tech industry, someone hasn't worked out how to make accurate progress bars? This migration I'm doing has sat on 'less than a minute' for over 30 minutes. I'm not an engineer; is it really that hard?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Why Is It So Hard To Make An Accurate Progress Bar?

Comments Filter:
  • by Anonymous Coward on Wednesday February 13, 2013 @12:17AM (#42879229)

    Comment loading ...

    • Can't Go Backwards (Score:5, Insightful)

      by naroom (1560139) on Wednesday February 13, 2013 @12:30AM (#42879363)
      Consider this: Once you've put progress on a bar, you can't take it off. Suppose you start a process that should take 20 minutes, and do the first 5 minutes, progress is now at 25%. But then, partway through, something unexpected happens and you realize the process is actually going to take 40 minutes. You can't take the progress "back" now, that would disorient the user. So you have to rescale the remainder of the bar.
      • by Jafafa Hots (580169) on Wednesday February 13, 2013 @12:31AM (#42879377) Homepage Journal

        I've seen some progress bars that do exactly that - go backwards.

        • Yes and it's those--as well as those that dance left and right for no damn reason--that really piss me off.

          • by The Snowman (116231) on Wednesday February 13, 2013 @01:08AM (#42879703) Homepage

            Yes and it's those--as well as those that dance left and right for no damn reason--that really piss me off.

            You mean like this one? http://xkcd.com/612/ [xkcd.com].

          • by hattig (47930) on Wednesday February 13, 2013 @07:27AM (#42881709) Journal

            I hate those, they're totally pointless. "I'm possibly doing something, I don't know how much of it I've done, and I don't know when it will end, and I won't show you when I started".

            To be honest, progress bars shouldn't be used for indeterminate timescales. If you can guess a time remaining, then say that, as this can be changed, and it is visually more useful than a context-less progress bar that can go in reverse.

            • outline format (Score:4, Insightful)

              by hierophanta (1345511) on Wednesday February 13, 2013 @12:07PM (#42884325)
              Progress should be reported to the user in outline format. Give the user the list of tasks that the computer is working on, show progress in each task. This is much more informative, and as a user - i'd feel more intimate with the process and in turn more trusting. also this might allow me to troubleshoot things that are moving slowly. some games are great at this, i've never seen it in an OS though.
            • by ArcadeNut (85398) on Wednesday February 13, 2013 @01:35PM (#42885309) Homepage

              I hate those, they're totally pointless. "I'm possibly doing something, I don't know how much of it I've done, and I don't know when it will end, and I won't show you when I started".

              To be honest, progress bars shouldn't be used for indeterminate timescales. If you can guess a time remaining, then say that, as this can be changed, and it is visually more useful than a context-less progress bar that can go in reverse.

              Well, they are not pointless. They let the user know "Something is happening, but I have no idea when it's going to be done.". If you don't do something like that, then the user thinks your app has locked up and they kill the application. It's called "User feedback".

              Now on to the original theme of the story....

              Progress bars shouldn't be based on time, they should be based on quantity of work. Typically when they do the marquee style of progress bar (where it just show animations, but no actual progress), it means the quantity is unknown. This happens in a lot of situations where the total number of steps to be processed is unknown due to the data, or the amount of time it would take to calculate the total number of items would take too long.

              Progress bars should also be a different subject then Time Estimates as they are not the same. I have 100 things to process, so my progress is between 1 and 100. How long that takes depends entirely upon what I am processing. If I'm processing Invoices say, then how long it takes depends a lot on what is involved with the invoice (line items, calculations, other look ups).

              Just because it took 10 seconds to process the last one doesn't mean it's going to take 10 seconds to process the next one. In order to determine how much time is left, what most people do is take the quantity left and multiply that by the average time it's taken so far. You could apply smoothing to the average (so it doesn't jump around a lot), but other then that, how else would you estimate the time? If the amount of time it takes to process items is fairly even, your estimate will be very accurate, if they are vastly different between items, then your estimate is going to jump all over the place and be wildly inaccurate.

          • Yes and it's those--as well as those that dance left and right for no damn reason--that really piss me off.

            There's one worse: A single progress bar animation that seems like it's working normally, gets to the end.... and then *starts over* (not the entire process, just the progress bar).

            That's worse than useless, it's utterly misleading. Either code a proper progress bar, add a second progress bar to indicate overall progress (assuming the first bar keeps resetting for every sub-task), or use one of those "indeterminate" animations. The "dance left and right" bars are attempts at one, but visually make no sense.

        • by shutdown -p now (807394) on Wednesday February 13, 2013 @01:04AM (#42879671) Journal

          I've seen progress bars that go backwards, but it usually indicates reversal of something that is done previously. E.g. in MS Office installer, if you cancel the installation midway through, it will "rewind" the progress bar while cleaning up.

        • by Agent ME (1411269) <agentme49@nOspAM.gmail.com> on Wednesday February 13, 2013 @01:06AM (#42879685)

          What? Why the fuck would a progress bar go backwards? A progress bar shouldn't be pegged to the fraction of time of the job done. It should be pegged to the actual progress. If progress starts going slower, then the progress bar should start moving slower.

          • by Arancaytar (966377) <arancaytar.ilyaran@gmail.com> on Wednesday February 13, 2013 @03:00AM (#42880407) Homepage

            Yeah, but then users complain because the bar is weirdly scaled, like 95% taking up a second and the remaining 5% an hour. You can try to profile it, but the actual time is determined by the local hardware after all: Processor speed, number of cores (which affects only some operations), network speed, free memory - there's no way to predict how much of the time will be spend on each task.

            (And if the progress bar isn't an indicator of execution time at all, then the arbitrary completion percentages assigned by the developer mean little. In that case, you may as well go back to hourglasses and spinning beachballs...)

            • by rioki (1328185) on Wednesday February 13, 2013 @04:46AM (#42880829) Homepage

              What I like is the Step X of Y types of progress indicators. Sure step 5 of 12 might take way longer then the rest but at least it is honest. It also helps to tell the user what it is currently doing. You know that downloading drivers may take a while when the internet is slow (or down).

              • by telchine (719345) on Wednesday February 13, 2013 @07:08AM (#42881597)

                Sure step 5 of 12 might take way longer then the rest but at least it is honest. It also helps to tell the user what it is currently doing.

                Reticulating splines?

          • by fnj (64210) on Wednesday February 13, 2013 @04:07AM (#42880681)

            Suppose a bar can never back up. Then its speed may vary enormously, making the visual how-done-am-I representation valueless.

            It is HARD.

            Define "fraction of job time done" numerically. Suppose you have to download 100 packages and then install them. How many % of the total should the download represent? Does the guy have cable or dialup? And how many % does the install represent? Does he have a slow USB hard drive or a ridiculously fast SSD? What if the first file downloads at 1 MBps and the 17th one at 139 Bps? I've seen that happen (varying server load, per-file mirrors). Which installs faster, a package containing 250 files totaling 10 MB, or a package containing 10 files totaling 100 MB - hint; it depends.

            Generally, might as well show a rotating propeller or a cylon helmet moving dot, neither of which has a beginning or an end. Just an indication that something is going on, and the system doesn't look frozen. Maybe a couple of numbers under it showing # files done out of # total files.

            • by thegarbz (1787294)

              I'd be happy with the bar just to indicate some form of total progress, quite unlike the latest trend in things like the Windows 7 installer. Why give a progress bar at all if it gets to the end and starts again at zero for some mythical next stage of the install progress?

          • by KitFox (712780)

            I know that NSIS Installers at the very least base the default progress bar internally* on the line number through the length of the entire set of installation process code. This makes it quite fun when you have long position jumps in the code or repeating loops that have enough code to cover a good chunk of progress. I would expect that several other installers may use the same base internal calculation of the progress bar.

            *The progress bar can also be controlled manually within the code for the coder to

        • by ibennetch (521581) <bennetch@gmail. c o m> on Wednesday February 13, 2013 @02:29AM (#42880273) Journal

          I think I prefer going backwards to what I once saw on (what I remember as) a Microsoft Office installation, probably 15 years ago. The progress bar ever so slowly crept upwards...98, 99, 100% done...then 101, and so on. It finally locked up somewhere after 140%.

          • by Quirkz (1206400)
            I saw a Mac OS 8 startup screen do something similar. It wasn't listed in percentages, but the startup screen had the empty box that the bar filled as it went. Then the filling color shot past the end of the bar and made it nearly to the edge of the screen before the whole box crashed.
      • by citizenr (871508) on Wednesday February 13, 2013 @12:35AM (#42879421) Homepage

        This is why you put two progress bars. One general and one for sub processes.
        http://www.codeproject.com/KB/progress/SplitProgressBar/SplitProgressBar.gif [codeproject.com]

        • by beelsebob (529313) on Wednesday February 13, 2013 @05:46AM (#42881211)

          No, no it isn't. A second progress bar flickering up and down all the time tells the user nothing. Just put the one general progress bar there, and you're done.

          • by chill (34294)

            No. You're wrong.

            This is a solved problem that was done, IMHO, good enough back in the mid-1980s on AmigaDOS.

            The AmigaDOS progress bar was actually two. The top one was the entire task - like installing the application. The bottom one was the individual action, like copying a file or updating a config.

            The were separated and there was a line of text over the lower bar telling you exactly what the current specific task was. Over the top bar was a line of text with a fraction showing you the number of total su

      • by asliarun (636603) on Wednesday February 13, 2013 @02:22AM (#42880235)

        To put it another way, it is impossible to make an accurate progress bar because it is impossible to predict the future. That's all.

        You can make assumptions, extrapolation, use past performance,etc but you are never going to get it accurate.

        This is like getting pissed at your GPS because it told you you will reach in 22 mins when it actually took you 35.

        It is either a dumbass expectation from the user or a dumbass design decision. You might have as well used an hourglass so the user could spend their time shaking it trying to get the sand to fall faster.

        • To put it another way, it is impossible to make an accurate progress bar because it is impossible to predict the future. That's all.

          A lot is just stupidity. When you copy lots of files on a hard drive, the time is proportional to some constant times total file size, plus some other constant times number of files. Lots of small files take longer than their size indicates. Most progress bars don't take that into account, so you make huge progress through a dozen 20 MB files, and then slow down through a lot of tiny files. Accounting for that alone would be a huge improvement.

          • by iapetus (24050)

            All these constants go out of the window if anything else starts accessing the drive as well, of course, and they're actually variable based on file system and a variety of other things.

      • by CAIMLAS (41445)

        Sorry, that's the wrong approach.

        The progress bar should not advance unless something has been completed. If you have it go back or have to rescale, then you should be using a different mechanism for determining completion.

        A more ideal way to do it would be with multiple process bars: a 'step' bar, and an overall progress bar. Step bars would be solely progressively linear. The progress bar would measure the steps. There are some tools which do this. The key point, I think, is that the overall progress bar

    • by dalias (1978986)
      If your installer is taking so long that the progress bar would be visible on the screen for more than 5 or 6 refresh cycles, you're doing something wrong and you should just give up.
  • Uhmmm. (Score:5, Insightful)

    by Fellon (1525917) on Wednesday February 13, 2013 @12:17AM (#42879235) Journal
    Yes it is "that hard".
  • Yes. (Score:5, Funny)

    by kc9jud (1863822) on Wednesday February 13, 2013 @12:17AM (#42879237)
    Yes it is. And to be fair, it's a lot more accurate than Nostradamus ever was.
    • by Pieroxy (222434)

      Yes it is. And to be fair, it's a lot more accurate than Nostradamus will ever be.

      There, FTFY.

  • because (Score:5, Insightful)

    by ILongForDarkness (1134931) on Wednesday February 13, 2013 @12:18AM (#42879241)

    Things are asyncronous. You wait for things from disk, ram, user input, over the network etc. How long it will take is non-deterministic. So a task composed of a bunch of these little pieces will be non-deterministic too.

    • Re:because (Score:5, Insightful)

      by eksith (2776419) on Wednesday February 13, 2013 @12:20AM (#42879259) Homepage
      This. Also, there may be other applications/processes that may start up, suddenly demand resources or jump in priority, which inevitably result in a progress bar going backwards.
    • Re:because (Score:5, Interesting)

      by geekmux (1040042) on Wednesday February 13, 2013 @12:27AM (#42879329)

      Things are asyncronous. You wait for things from disk, ram, user input, over the network etc. How long it will take is non-deterministic. So a task composed of a bunch of these little pieces will be non-deterministic too.

      If this is true (which it is), then logic would dictate that it is pointless to represent a progress bar in measurements of time.

      Perhaps the larger question is how much longer are we going to continue acting stupid about it, rather than trying to make a clock out of it.

      • by marnues (906739)
        As long as people want to know how much longer it takes. We operate in time. This is why progress bars are so prevalent even though they aren't accurate.
      • Well we do this in the real world too though say asking the mechanic when you can get your car back. Just asking wastes resources and means the answer is "later than it would have been before you interrupted". But even with a rough estimate is usually pretty good (except when it isn't and then it really isn't like installing apps and seeing 10min go to 2hrs) and can adapt to changing data. I think the problem is expectations: we want exact answers which is understandable if you are waiting for something (I

    • Re:because (Score:5, Insightful)

      by NotQuiteReal (608241) on Wednesday February 13, 2013 @12:38AM (#42879449) Journal
      Plus, you are lucky even get a "guesstimate bar". Showing progress with bad estimates is more reassuring than just a "working on it spinner". Either is an order of magnitude better than an unresponsive GUI because the programmer didn't put that stuff in another thread.

      Personally, I like the "list of what I am going to do + check them off as they are done" approach, if the "progressing task" is of varying descriptions.

      That said, for some tasks, you have to consider the "Heisenberg effect" a bit, depending on the work being done - do you want your progress bar pestering the "worker" for progress reports all the time, or just doing its job.
      • Re:because (Score:5, Insightful)

        by ILongForDarkness (1134931) on Wednesday February 13, 2013 @12:53AM (#42879573)

        The list/status bar solution is nice for another reason: if your program does hang your users know where in the process it happened. You get more useful feedback from the users, sometimes they might be able to troubleshoot it themselves (oh it is dying when connecting to my fileserver, perhaps I"m not connected to the network). Heck it is useful for course grained optimization you see the logical steps that take the most time and can drill down into speeding them up as much as possible.

  • Various reasons (Score:5, Insightful)

    by GoodNewsJimDotCom (2244874) on Wednesday February 13, 2013 @12:19AM (#42879249)
    One reason is the progress bar starts out as just a generic tool to show that your loading hasn't froze. At first it is parsed correctly with the elements to be loaded, but as scope increases and more things load, it can get sketchy later on.

    Another reason is it is difficult to estimate time left. If you look at some old FTP programs, they'd estimate the rest of the download's time based on how fast the previous has taken. Future lag, fragmented files, etc aren't taken into consideration.

    There's a bunch more reasons, but namely the progress bar's main purpose is to show you that the whole system isn't locked up, which they've been doing well for the past 30 years or so.
    • This is why if it is something the user will understand I like to use a status bar instead. Much nicer to see things moving through a workflow than trying to guess how long the db load vs analysis will take and display the progress bar correctly which will change as the data grows, complexity of the problem, computer the user is on etc. Progress not timing, we should just completely remove the complete from the visual just have a numerical counter, if it is increasing things are still working.

  • sometimes (Score:4, Informative)

    by MrDoh! (71235) on Wednesday February 13, 2013 @12:20AM (#42879257) Homepage Journal
    Copying files. Sure, get a list of the files to be moved, get the size, as files go across, start the % progress meter. What if the network starts slowing down as you start to copy? New files are added. You used a rough calc to get a vague idea as it was 10x faster, but when you start copying, there's a lot of files bigger than you thought. Network's fast, but the end machine you're copying too is having problems keeping up. You start hitting cache, it was fast (and skewed the result) till then, now it's crawling. Installations. All the fun of copying files, but you're updating existing files too, file system may be fragmented, some of the .ini files as you get to may need extra work. Drivers to install may take longer than expected. Once installed, you have to generate/compile/download extra, that's more rough guesses. As long as the hourglass/cursor/spinner is spinning, and the %'s is going up now and then, probably the best you can ask for. The trend for guesstimating time remaining seems to be diminishing, as surely the main thing most people want is to know 'is this still working or has it hung?' for anything else, logcat/catch stderr'more details' to find out what it's actually doing. It COULD be more accurate perhaps, but you'd spend so long working it all out in advance, for 9/10 things, it'd have been quicker to just do it.
  • Yes (Score:4, Insightful)

    by Austerity Empowers (669817) on Wednesday February 13, 2013 @12:20AM (#42879261)

    It's very hard to predict how long something will take, particularly in relation to other things, if what you're writing is going to be on any number of platforms with different processors, storage, memory and network situations.

    You can be reasonably accurate with it, far more than my favorite 99% in 1 second, the last 1% in one hour scenario. There are cleverer and cleverer ways of making it ever more precise, but those methods usually involve spending time on getting it right, and not many people do it.

    • Re:Yes (Score:5, Interesting)

      by greg1104 (461138) <gsmith@gregsmith.com> on Wednesday February 13, 2013 @12:42AM (#42879491) Homepage

      I would have stopped at "yes" without the optimism, and it's not even a platform/processor issue. This is a fundamentally unsolvable thing, since in some cases it reduces to the halting problem [wikipedia.org]. That best you can do is come up with an approximation.

      But the approximations will be wrong too. Simple example: write speed. If you write a block to disk, and it fits into the operating system cache, a write happens almost instantly. If the cache is full, you might have to spend tens of seconds waiting before that write occurs. Here's what happens with installers, copy programs, and a large chunk of other things. You write until the cache fills, and those happen at memory speeds. Then, all of the sudden, you grind to a halt when the cache fills. You won't see any progress, sometimes for minutes--it can take a while to chug through gigabytes of random writes. I show an example of this on my blog on Linux [blogspot.com], and this problem gets worse as memory increases, not better.

      What does that look like to the user? They get a progress bar, it zooms along for a while, and then it cranks to a halt. Then it hangs for a bit, starts moving, and the whole thing completely changes scale. Does this sound familiar? That's what people complain about, right? You can't make that go away without building a model of the caching mechanism that's more accurate than the cache itself. After all, if you could predict this was coming, the OS could have done a better job scheduling I/O with that information, too. Think about that for a minute: to write a really good progress bar for write operations, you have to do a better job on I/O scheduling than Linux does.

      If you step back and say "well let's approximate how long disk I/O takes then and base the bar on that", you'll discover that doesn't work either. There's over a 100:1 difference between the fastest and slowest storage on the market. Good luck modeling that accurately enough to predict the future, too.

  • The AMD Catalyst installer progress bars are my favorite comedy example. It's jarring that such a high-profile product can have such a hacked solution in place.
  • I think that I can say it seems like some have gotten better, like large file copy dialogs no longer seem like a suggestion

    But, I have to agree that more complex operations like OS installations seem to be out to lunch, I can remember years ago joking about "Microsoft Minutes" during what seemed like Windows Marathon installations. I think with the array of processors, HD speeds, SSDs, etc, perhaps we should dump the x minutes remaining, and rather look at a percentage completion factor, although this too

  • by Punto (100573) <`moc.liamg' `ta' `botnup'> on Wednesday February 13, 2013 @12:22AM (#42879273) Homepage

    There's probably a pantent for a "method or apparatus for an accurate display of progress", nobody wants to mess with that (but seriously most of my innacurate progress bars deal with unpredictable things like I/O, or non-uniform sets like loading textures and meshes and animations all together, so who knows how much time it will actually take to process the same ammount of data?)

  • Unfortunately, one does not know the exact running time "a priori" - it varies widely with different hardware configurations, network congestion, hard drive speeds and is therefore often easier to measure than to predict.

    The progress bar has always been a "best effort" guess as to the amount of time remaining, I think they have gotten a lot more accurate over the years - but perfection is a long way off I suspect.

  • Progress bars are all about using past history to predict future performance. The problem is that past history doesn't always say anything about what will happen in the future.

    If you only use very recent history then you can usually better predict the very near future but it also makes the progress prediction and remaining time prediction very unstable and jump all over.

    You're a human so use your own intuition to predict progress in part on what the program tells you and in part based on your knowledged of

  • It is sometimes hard to make a good progress bar for certain procedures. In such case, please don't even try. No one wants to see those bars that sit at 0% for three minutes and then jump to 100%. Leave the progress bar out completely or use one of those "infinite" bars that just have block sliding from left to right, or the Win8 spinning pearls animation.
  • by PseudoThink (576121) on Wednesday February 13, 2013 @12:27AM (#42879337)
    See http://scribblethink.org/Work/kcsest.pdf [scribblethink.org] and http://scribblethink.org/Work/Softestim/softestim.html [scribblethink.org]

    (No, I'm not being serious. The topic just reminded me of when I once jokingly justified a poorly estimated ETA on a "simple" development project by referencing the above paper.)
  • MSIE (Score:5, Interesting)

    by Anonymous Coward on Wednesday February 13, 2013 @12:29AM (#42879351)

    My favorite terrible progress bar was Internet Explorer, back in its early days of essentially being a renamed version of NCSA Mosaic. When attempting to load a site that wasn't available, the progress bar would slowly creep towards complete, despite the server being completely unresponsive. Then after a long while the browser would give up and stop the progress bar. Why on earth would the progress bar move if the server is completely unresponsive? Who programmed this? I would hope that they, like the inventor of Clippy, suffered a terrible death by fire.

    • by blueg3 (192743)

      Are you kidding? Lots of processes still use that damn indefinite progress bar. I think a recent version of IE might, even. As time progresses, even if no real progress is made, it fills up some small fraction of the remaining space. The next block of no-progress "time" uses up the same small fraction of the *now-remaining* space, so the progress bar creeps forever toward the end, even though no progress is made.

  • It is quite trival actually.

    This one is always perfectly accurate:
    zenity --progress --text="Testing..." --title="Test" --auto-close --pulsate &
    PID=$!
    Do whatever...
    kill $PID

  • Cost Benefit (Score:5, Informative)

    by infernalC (51228) <matthew.mellon@g[ ]le.com ['oog' in gap]> on Wednesday February 13, 2013 @12:32AM (#42879381) Homepage Journal

    Progress bars do not make sequences of actions complete any faster. In fact, they make them slower.

    That being said, take for example an installer that must perform the following steps during an upgrade:

    0. Figure out how many files need to be replaced.
    1. Replace 30 files of varying sizes.
    2. Add 10 files.
    3. Update a half million rows inn a table with a million rows setting a column to a computed value based on some predicates.
    4. Run a third party installation mechanism (MSM?) for a supporting library, etc.

    Modern computers are time-sharing systems. Each process that involves computation is at the mercy of the scheduler in the kernel to give it the cycles it needs to complete. That means that even if you measure the time it takes to complete some process, it's not going to be the same a second time, because the installation process doesn't get undivided attention.

    Steps 0 - 2 - you're at the mercy of the IO buses, hard disk, antivirus software interfering, etc.
    Step 3 - What shape are the database statistics in? How efficiently can you apply the predicates? What does the distribution of the data look like? You can't tell this ahead of time...
    Step 4 - Does this third party installer provide you some sort of metrics as it runs?

    These are the sorts of problems to be overcome to do an accurate progress bar. In short, they aren't worth overcoming.

  • by at10u8 (179705) on Wednesday February 13, 2013 @12:34AM (#42879405)
    For over 50 years rocket launch countdowns have not run in a linear fashion, sometimes even being set backwards.
  • For complex operations, doing accurate progress may take a lot of development time you can't afford. Mostly everyone has deadlines...

  • ...would be a PB combined with some way for the app and OS to tell me why things have slowed down, in plain language. This would not be impossible to do.

  • I'm convinced that it's just a random number generator. Half the time it gets to 50% in an hour, jumps to 75% in ten seconds, then finishes. Other times it grinds away at a job for the full estimated time. Which changes constantly.

  • Physics! (Score:5, Funny)

    by ignavus (213578) on Wednesday February 13, 2013 @12:42AM (#42879479)

    You can work out where you are (% completed) or how fast you are going (rate at which the progress bar is growing), but not both at the same time.

    It's simple quantum mechanics.

  • by gargleblast (683147) on Wednesday February 13, 2013 @01:15AM (#42879771)

    It is hard to make an accurate progress bar because it shouldn't be a bar at all - it should be a graph.

    Consider the humble download: bytewise, it might be 97 percent complete, but at the last moment, the bps rate has fallen. With a progress bar indicating a percentage and an estimated time, it might say 97% complete, 3 seconds to go. If the progress indicator was a graph, you could tell that the bps rate has fallen, and that the 3 seconds to go estimate (probably based on a linear extrapolation of progress to date) does not apply.

    I have never seen it done though. Partly, because I have never done it.

  • ... when we solve the halting problem. I'm not entirely joking. The main problem with progress bars is that, quite often, it is not possible to accurately estimate how much time is needed to complete a problem (i.e. for the program to halt).

  • The 99%... (Score:5, Insightful)

    by DavidD_CA (750156) on Wednesday February 13, 2013 @01:37AM (#42879951) Homepage

    The public opinion of the Progress Bar would be considerably more favorable if programmers would simply treat 100% as if it were 75%.

    In other words, do all the stuff you have to do, measuring progress and whatnot, but when you're actually at 80%, report yourself at 60%. Likewise, when you're at 95%, say you're at 70%.

    Then, only when you really are completely finished, you jump from 75% to 100% in under a second.

    Complaints gone.

  • by k3vlar (979024) on Wednesday February 13, 2013 @01:38AM (#42879969)
    You know what I'd like to see more than a working progress bar? A "Cancel" button that actually stops the f*%! process! .
    I don't want to finish the sub-process I'm currently doing (which has probably stalled)... just FREAKING STOP.

    If you (programmer) want to close connections, or save the changes to the disk, do it in the background. Making me sit there for another 10 minutes while you're "cancelling..." is not helpful. I will force close your program. Failing that I will hard-reset the computer. Seriously.
  • by PPH (736903) on Wednesday February 13, 2013 @01:59AM (#42880127)

    ... a functional progress bar in 5 years.

    No, wait. It seems to have stalled.

  • by dcollins (135727) on Wednesday February 13, 2013 @02:16AM (#42880197) Homepage

    "How come after 25 years in the tech industry, someone hasn't worked out how to make accurate progress bars? This migration I'm doing has sat on 'less than a minute' for over 30 minutes. I'm not an engineer; is it really that hard?"

    Yes, because all progress bars are inherently a prediction of things that will happen in the future. If there is any error condition, unusually large blob of data or weirdly structured hard drive to read from, varying bandwidth bottleneck, fritzy peripheral not responding as expected, etc., etc. times a million, then the unusual event will make the prior prediction incorrect and look silly in retrospect. As long as there is any "if-then" clause or error handling in the branches in the system, then the unexpected can happen and make the prediction (progress bar) invalid.

    It's analogous to weather prediction. It can't be perfect, it's an extrapolation, but people will always complain about it.

  • by Greyfox (87712) on Wednesday February 13, 2013 @03:06AM (#42880431) Homepage Journal
    We'll be sure to take a resource off of developing the application we're selling and get him right on that! Oh, no it's quite all right, the schedule's slipped 14 times since we started, but the schedule can just take one for the team, can't it? After all, you have to know how long that thing you're going to do ONE TIME is going to take! It's not like your computer can do TWO THINGS or anything! We wouldn't expect you to do something ACTUALLY PRODUCTIVE rather than watching our progress bar!

    Is why.

    Hmm. I wonder if I wrote an app that was nothing BUT progress bar, if people would go for it.

    Some developers have already come to the conclusion that installation is a prime advertising timeslot. So even if anyone was inclined to write a progress bar, it'll still end up ad-laden and annoying.

  • Simple solution (Score:4, Insightful)

    by DerPflanz (525793) <bart.friesoft@nl> on Wednesday February 13, 2013 @04:22AM (#42880739) Homepage

    Show progress of the work, not the time. You never know what other things the machine is doing, and is better to give no estimate than a bad one.

    And don't suffice with a bar, also provide information on what the process is doing.

  • by ae1294 (1547521) on Wednesday February 13, 2013 @05:15AM (#42881001) Journal

    This problem was solved a long time ago... I still wonder why people don't know how to code a proper progress bar...

    HOWTO:

    Setup bar, value set to 0%
    Create link-list of all files to transfer with their size in blocks, zeroed time in msecs, & Boleyn value for iftransfered.
     
    Transfer available buffer * 2, update link-list times for each file transferred and mark iftransfered true. Use following file selection method from link-list choices:
     
    Rand(Total files).
    iftransfered = True then +1 until false or (Total Files) reached.
    If (Total Files) reached then -1 until all files transferred = True.
     
    Calc buffered transfer & unbuffered transfer times using link-list data.
    Update untransferred files link-list times based on above using 71% weighting of unbuffered over buffered times.Update display
    Transfer 1x buffer update link-list & evail difference between first and second transfer. Adjust weighting using following:
     
    Pick random # between 1 and 661 + 42^2 * last weighting.
    Divide until less than 100.
    If less than 89 then random # above - sqrt42 * first weighting.
    Again divide until less than 100.
    If less than 41 then transfer 4x buffer. repeat buffered time weight calc. goto pick random 1 and 661 step.
    If above step repeats more than thrice adjust plank constant up by 11.11% & factor new weightings. Store in reg.
    If above above step repeats more than 7 times adjust plank constant down by 11.11% and factor new weightings. Store in reg.
    Update display, if greater than 100% than 100%.
    If number is irrational do 2D4 damage unto number until it becomes rational again. update display.
    Continue transfiguring & updating link-list and weights as above so as below.
    If time remaining goes negative check if users name begins with bob. Display Improper observer, recalc from start with different observer.
    If time goes infinite check on cat. If dead display Improper universal constant detected. Invert plank constant. recalc from start. Store regValue TimeFlow Inverse = True. Check at start to avoid problem. NOTE: program should check that user has not switched universes every x transfers or in background test transfer at idle.
    If above happens thrice then cthulhu re-entering universe probability approaches infinite. Halt transfer. Terminate user. display greetings...

    I've left out the easy stuff but this provides for a 99% correct est. Please note that the computer must be from 1 year in the future for this to exceed 87% correctness without causing time dilation within progress meter by blocks remaining^66 msecs. Check Mfg date at start and adjust time est accordingly.

    The above is copy-written and my not be used....

Whoever dies with the most toys wins.

Working...