• (cs)

    Surely, there must be a more elegant way of doing this. Perhaps involving XML...

  • Matt H. (unregistered)

    Yeah, I really hate it when people knowingly write ineloquent code. Causes so many problems.

  • Ian (unregistered)

    Ah, the good old "Microsoft totally did it!" defense. Works every time.

  • (cs)

    I can't think of any clever or even snarky way of pointing out that 1/5 != 0.5

  • (cs)

    Why use a progress bar then? If they can't determine the progress, all they need is an animated throbber to show the user that something is happening and the software isn't frozen. There should be an obligatory UI class at CS courses.

  • Ocson (unregistered)

    Yet another tale of lowering the bar.

  • Anon (unregistered)

    http://xkcd.com/612/

  • highphilosopher (unregistered)

    It's good to know that Microsoft is lowering their standards.

  • Name (unregistered)

    Someone needs to tell them about marquee scroll

  • Mike Caron (unregistered) in reply to dpm
    dpm:
    I can't think of any clever or even snarky way of pointing out that 1/5 != 0.5

    Let me try:

    "Hmm... 0.5 == 0.2? This must be that 'new math' I keep hearing about..."

    2nd try

  • (cs)

    I totally understand the microsoft standard part of the comment though. I've lost count how many times i've seen a MS app show a progress bar sitting at 100% for minutes with a "Please wait..." above it (or something equivalent).

    Or even better, progress bars that move from 0 to 100%, then do so again...and again...and again...and again...

  • Dignissim (unregistered) in reply to Kiss me I'm Polish
    Kiss me I'm Polish:
    There should be an obligatory UI class at CS courses.

    Q Effing T

  • Raw (unregistered)

    Actually, the Microsoft way it to have the bar asymptotically increase towards 100% on a timer, never really reaching it. When the task is done, they just slam it to 100% and finish. This is used, among other places, in Microsoft Access.

    Actually, it's a pretty neat solution for those situations where you can't get any status updates, you just know when it's finished. I've used an enhanced variant of it myself several times.

  • (cs)

    They must certainly be using Microsoft coding conventions with those stupid leading underscore member names.

  • Anonymous Coward (unregistered)

    Obviously none of you know how the windows service start and stop progress bars work. It's a little more sophisticated, but is basically the same principle

  • (cs)

    Guess the original programmer had never heard of progress bars with "marquee" state... even MS uses them now.

  • War And Progress (unregistered)

    Well, if you really have no idea, what are you going to do? Users don't like seeing nothing, they think it's crashed.

    The only thing that is wrong with progress bars is when you have a bar that gets to the end and then it is replaced by another that starts at 0 again. What is the point of telling me how far through one step I am - especially if there's an unknown number of steps? Windows & Office setup are definitely guilty here.

    My favourite is if you cancel (again, Office Setup springs to mind) and they run the progress bar backwards to signify undoing what they've done.

  • Richard (unregistered) in reply to Raw
    Actually, the Microsoft way it to have the bar asymptotically increase towards 100% on a timer, never really reaching it. When the task is done, they just slam it to 100% and finish. This is used, among other places, in Microsoft Access.

    That's what we did in our webapp a few years ago. It sounds awful, but our users wanted some kind of moving progress bar (not just a cylon-style moving animation), and they were actually very happy with it. We didn't ever bother reaching 100% since when the task was over the new page would be delivered. Just use an exponentially increasing sleep amount, and only start about 1/2 second after the new page was requested.

    We played around with the idea of measuring weighted average wait times to come up with a better bar, the same way that Hudson does for its tasks, but it turned out that everyone was basically fine with it once we made a couple of tweaks to the scaling.

    Shrug...

  • Inno (unregistered)

    Minor WTF:

    int _percentage = R.Next(Convert.ToInt32(.5 * _bar.Maximum));

    For the better:

    int _percentage = R.Next(_bar.Maximum / 2);

    Or worse:

    int _percentage = R.Next(int.Parse((.5 * _bar.Maximum).ToString()));
  • captzimmo (unregistered)

    I knew it! I knew that those things were actually Placebo Bars

  • Richard (unregistered) in reply to Anonymous Coward
    Anonymous Coward:
    Obviously none of you know how the windows service start and stop progress bars work. It's a little more sophisticated, but is basically the same principle
    Actually its better than that. I love how they'd use several steps to disguise how long something actually too. IIRC it was the WIndows 95 (maybe ME) installation disk that started copying files but spent the first 1/3 or so of the time "determining available disk space", with a progress bar, while frantically spinning the disk.

    And of course, obLink: http://xkcd.com/612/

  • Incourced (unregistered)

    Apple used the WaitingForLoginWindow in 10.4, where they estimated how long to set the progress bar to based on the time it took last time. It is a fairly reasonable guess in most cases. But I would vote for a throbber. Why imply that a task will ever finish?

    CAPTCHA: 'ingenium' - a mineral that James Cameron inhales to come up with mineral names.

  • (cs) in reply to Richard
    Richard:
    And of course, obLink: http://xkcd.com/612/
    And of course, obRTFC.
  • (cs) in reply to Kiss me I'm Polish

    Your UI class should have explained that people hate irrelevant UI like the looping progress bars or little animations. The progress bar is calming, since you can see that progress is being made and you'll know when you've stalled.

    Note how GMail could easily have gotten away with a "throbber" but they put in the extra work for a progress bar, and even though it preforms in a rather jumpy manner, it's infinitely better than "Loading" with an animated ellipse.

    As a developer I can't say I endorse the random bar, much as I hate progress indicators that don't actually indicate any progress I've used them when needed. However, as a user, I can tell you that if I can't peek at the source behind a jumpy or random-looking progress bar, and I just have to accept it and mostly use my own estimates, my brain still prefers it.

  • StarLite (unregistered) in reply to Richard

    [quote user="Richard"][quote user="Anonymous Coward"]IIRC it was the WIndows 95 (maybe ME) installation disk that started copying files but spent the first 1/3 or so of the time "determining available disk space", with a progress bar, while frantically spinning the disk.[/quote] Technically the text could be true.

    1. The setup gathers the required components to install
    2. The setup reads all the filesizes of the components on the cd.
    3. Adds them all up and determines if there's enough space.

    Offcourse this is far from optimal, especially on slow media like floppies, CD's and DVD's, but the message 8could* have been legit.

  • Anonymous (unregistered)

    This is pretty horrific and I'm sure it's not a "Microsoft Standard" [b]but[/i] Microsoft certainly have done it before. Internet Explorer anyone? In the last version I used (v6.0), the progress bar would very slowly increment at all times, irrespetive of whether there is any data being sent or received from it. They probably thought to themselves "we can't stop the progress bar when the network gets interrupted, people will think IE is broken!". And it is.

  • Grovesy (unregistered) in reply to frits
    frits:
    They must certainly be using Microsoft coding conventions with those stupid leading underscore member names.

    In the part of the organisation I was in at MS, nope... the standard resharper settings did a nice squiggly 'rename this please' message under any field prefixed with a _

    If you were unlucky enough to be on a project with an anicent version of StyleCop plugged into the build progress, _ prefix would have broken the build...

  • despot (unregistered)

    You can take it too far tho. I worked at a place once (game development (and yeah, the ramen noodles thing isn't a myth, they don't pay very well) where a simmilar situation arose "need to display progress, no status event." The lead developer's solution involved standardizing the results of all known installs based on a value passed back as part of the activation process, along with some machine specs... and then conversion to the complex plane, and an integral transform or two thrown in for good measure.

  • eViLegion (unregistered)

    Code that needs elocution lessons?

  • Anonymous (unregistered) in reply to frits
    frits:
    They must certainly be using Microsoft coding conventions with those stupid leading underscore member names.
    What do you use? Our shop used to use m_xxx for members but we went over to the Microsoft conventions a while ago so now we use exclusively _xxx for members. This is an improvement if only because all member variables are one character shorter and minimising line length is fundamental to improving readability. It's a small improvement but an improvement nonetheless. So what's your solution, frits?
  • kjordan (unregistered) in reply to dpm

    Maybe for extremely large values of 0.2?

  • (cs) in reply to Kermos
    Kermos:
    I totally understand the microsoft standard part of the comment though. I've lost count how many times i've seen a MS app show a progress bar sitting at 100% for minutes with a "Please wait..." above it (or something equivalent).

    Or even better, progress bars that move from 0 to 100%, then do so again...and again...and again...and again...

    Adobe is far worse. Instead of using Windows controls, they create their own. The progress bar jumps around from below 20% to about 90% then back to about 10%, et cetera!

    A progress bar, as a User Interface, must establish a user's expectations. It is not simply eye-candy.

  • justsomedude (unregistered) in reply to Severity One
    War And Progress:
    The only thing that is wrong with progress bars is when you have a bar that gets to the end and then it is replaced by another that starts at 0 again.

    What is the point of telling me how far through one step I am - especially if there's an unknown number of steps?

    I disagree that this solution is bad in all cases. To answer your question - the point is twofold: 1) Show you the appliation hasn't crashed. 2) Leave the developer with some small amount of sanity by using a value that does actually represent something real, instead of just making stuff up.

    Personally, I prefer this solution to marquee-type progress bars. They are no less useful and actually are saying somehting real, isntead of just demonstrating the app can still handle events or animations.

  • (cs)

    TRWTF is that Alex deletes inane frist posts, but allows xkcd links.

  • Crinkle (unregistered)

    As others have pointed out this code is dumb, but the idea of giving the user an insight, even if it is almost entirely unrelated to what's actually happening, is fine. I have used this in deployed applications. Users will wait at a static screen for approximately ten seconds before they start slamming their hands on the keyboard and click-spamming cancel.

    A progress bar distracts them enough to play nice. As long as it doesn't outright lie (i.e. 100% means done, 0% means starting, no change in progress bar means something's frozen up) it keeps resetting their ten second attention span. It also tricks them in to thinking the application is a lot faster than it really is. A one minute 'hung' screen feels much longer than a one minute progress (distraction) bar moving around.

  • Fred (unregistered) in reply to Anonymous
    Anonymous:
    frits:
    They must certainly be using Microsoft coding conventions with those stupid leading underscore member names.
    What do you use? Our shop used to use m_xxx for members but we went over to the Microsoft conventions a while ago so now we use exclusively _xxx for members. This is an improvement if only because all member variables are one character shorter and minimising line length is fundamental to improving readability. It's a small improvement but an improvement nonetheless. So what's your solution, frits?

    howabout not prefixing with anything?

  • Anonymous (unregistered) in reply to tOmcOlins
    tOmcOlins:
    TRWTF is that Alex deletes inane frist posts, but allows xkcd links.
    Not a WTF - the mods delete irrelevant posts and "Frist" is clearly irrelevant; however, the xkcd links do normally have something to do with the article.
  • Saving It (unregistered) in reply to Kiss me I'm Polish
    Kiss me I'm Polish:
    all they need is an animated throbber to show the user that something is happening

    Maybe something is happening, but you keep your animated throbber to yourself, pal!

  • Anonymous (unregistered) in reply to Fred
    Fred:
    Anonymous:
    frits:
    They must certainly be using Microsoft coding conventions with those stupid leading underscore member names.
    What do you use? Our shop used to use m_xxx for members but we went over to the Microsoft conventions a while ago so now we use exclusively _xxx for members. This is an improvement if only because all member variables are one character shorter and minimising line length is fundamental to improving readability. It's a small improvement but an improvement nonetheless. So what's your solution, frits?
    howabout not prefixing with anything?
    No good - I want my member variables to be grouped alphabetically, so they need some sort of consistent prefix.
  • Anonymous (unregistered) in reply to Fred

    How about not confusing member variables with locals?

  • Anonymous (unregistered) in reply to Crinkle
    Crinkle:
    As others have pointed out this code is dumb, but the idea of giving the user an insight, even if it is almost entirely unrelated to what's actually happening, is fine. I have used this in deployed applications. Users will wait at a static screen for approximately ten seconds before they start slamming their hands on the keyboard and click-spamming cancel.

    A progress bar distracts them enough to play nice. As long as it doesn't outright lie (i.e. 100% means done, 0% means starting, no change in progress bar means something's frozen up) it keeps resetting their ten second attention span. It also tricks them in to thinking the application is a lot faster than it really is. A one minute 'hung' screen feels much longer than a one minute progress (distraction) bar moving around.

    This is exactly why we have "indeterminable progress" icons. Like the spinning wheel in Firefox - it doesn't count up anythng, it just spins indefinitely to show that something is happening. If you can't measure progress you should NOT be using a progress bar - you should be using an indeterminable progress animation.

  • Crinkle (unregistered) in reply to Anonymous
    Anonymous:
    This is exactly why we have "indeterminable progress" icons. Like the spinning wheel in Firefox - it doesn't count up anythng, it just spins indefinitely to show that something is happening. If you can't measure progress you should NOT be using a progress bar - you should be using an indeterminable progress animation.

    I know, and I have used those too. But they don't affect people as much as the progress bar. They can easily assume something has frozen even if it is animated. The trick works best with progress bars because they don't repeat.

    I guess people are just too trusting of software. They don't seem to think that a computer, a modern wonder of engineering and mathematics, might be doing something as dumb as saying "pffft it'll be done in 30 seconds or whatever lol".

  • Still Not Tim (unregistered) in reply to Anonymous

    Speaking of the Firefox "spinning wheel"...

    There are plans afoot to change that where appropriate.

    In the "Minefield" builds the "spinning wheel" is mostly replaced by a circle that fills in to indicate percentage completion.

    This may or may not be the final version - it's still under consideration.

  • SR (unregistered) in reply to Anonymous
    Anonymous:
    This is exactly why we have "indeterminable progress" icons. Like the spinning wheel in Firefox - it doesn't count up anythng, it just spins indefinitely to show that something is happening. If you can't measure progress you should NOT be using a progress bar - you should be using an indeterminable progress animation.

    AKA the animated throbber.

    PS I agree completely.

  • Anon (unregistered)

    TRWTF:

         for (int i = 0; i < _bar.Maximum; i++) 
     { 
         if (i == _percentage) 
         { 
             //execute the real code 
         }

         // Always perform progress step 
         _bar.PerformStep(); 
     }

    So I'm assuming PerformStep is supposed to prompt the GUI thread to force it to redraw, presumably with some kind of small delay (so you can see the intermediate steps), which means that this code forces the user to wait while the program does some pointless animation before it even starts doing the task. Start the task in another thread immediately and then play around with the progress bar while the task is being done.

  • Steve the Cynic (unregistered) in reply to Crinkle
    Crinkle:
    A one minute 'hung' screen feels much longer than a one minute progress (distraction) bar moving around.
    A *one*-minute hung screen feels much longer than a *two*-minute whirlygig. However, not all whirlygigs are equally useful.

    There are four main types:

    • Measurable-work known-job-size with a consistent relationship between increments of work and time taken. This produces a steady march of progress.
    • Measurable-work known-job-size with no consistent relationship between increments of work and time taken. This produces a bizarre impression, especially when the first and last of 20 chunks take 10 seconds each, and the other 18 take the 10 seconds in between.
    • Measurable-work unknown-job-size, like copying large quantities of files in a deep hierarchy. Unless you spend time bouncing around the directory tree first ("Preparing to copy...", anyone?), you cannot know how much work is to be done, but you can show the amount of bytes copied.
    • Non-measurable-work. This requires the program to commit fiction, in that it cannot show its progress, because it has no idea how much progress it has made. This shouldn't ever happen. You can always report the number of megabytes copied, files deleted, fleens ogglefloggled, etc.

    paratus: machinery without an ap.

    An Error Occurred. An Error Occurred.

  • Quirkafleeg (unregistered) in reply to Crinkle
    Crinkle:
    I guess people are just too trusting of people.
    FTFY :-)
  • () (unregistered)

    .5 * _bar.Maximum = 1/2, not 1/5

    Captcha: opto

  • RBoy (unregistered) in reply to tOmcOlins
    tOmcOlins:
    TRWTF is that Alex deletes inane frist posts, but allows xkcd links.

    Or that all frist posts are deemed inane, and persto! they are gone.

  • • by (unregistered)

    This method could be so much more eloquent if instead of a progress bar it just displayed that comment character by character.

Leave a comment on “Meaningless Progression”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article