why do progress bars suck so much?
-
- Why would you make a progress bar that goes to 99% in 3 seconds, then stays there for 5 minutes? - Why would you make something that looks like a progress bar, but just runs back and forth in a container? - Why give me the illusion that this will be quick, then have me wait for 10 minues for that last %? Or worse, show me 100% for 10 minutes? - WHY? WHY? WHY? Make a progress bar that is usefull! Or don't make one! If it doesn't work, delete it, and replace with a loading animation that doesn't give false expectations. If you are a programmer, and made a crappy, misleading progress bar... I HATE YOU! :mad::mad: So, why are you releasing software with a feature that obviously doesn't work!? How f'ing hard is it to make one that works? If you can't, I think there's an opening there. *points you to mc donalds job board* If you're the manager that said "ok" to that, look here for an opening. *points to suicide booth* F F F F F FFS! #"%¤%! #&"¤"! There. I feel much better now. :-D
Technically speaking it is not the developer of the PB that sux but the one that decided to use it and it using it improperly that sux ;P Just saying. Also, I have been in the case where I had a nice even flow of progress. Then through some extending of the app the PB seems to hand (one end or the other.. Very rarely in the middle, although it happens as well). Take a File Reading process for example: Teh system first checks the count of files and then begings processing them, updating the PB as it finishes. But some nuckle head end user thought it would be a good idea to group 100K of his files into one file. Now the PB calculation is off because that one stupid file is actually 100K files worth of data. Granted, the developer could have checked the size etc. but then every EU has to wait longer because of that one stupid EU that thought it was a good idea to make such a large file. Again, just saying its not always the Devs fault. Deffinately it is rarely the PB devs fault. And often it is the systems fault for not being like the test system :-D
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
- Why would you make a progress bar that goes to 99% in 3 seconds, then stays there for 5 minutes? - Why would you make something that looks like a progress bar, but just runs back and forth in a container? - Why give me the illusion that this will be quick, then have me wait for 10 minues for that last %? Or worse, show me 100% for 10 minutes? - WHY? WHY? WHY? Make a progress bar that is usefull! Or don't make one! If it doesn't work, delete it, and replace with a loading animation that doesn't give false expectations. If you are a programmer, and made a crappy, misleading progress bar... I HATE YOU! :mad::mad: So, why are you releasing software with a feature that obviously doesn't work!? How f'ing hard is it to make one that works? If you can't, I think there's an opening there. *points you to mc donalds job board* If you're the manager that said "ok" to that, look here for an opening. *points to suicide booth* F F F F F FFS! #"%¤%! #&"¤"! There. I feel much better now. :-D
I think it's time for a more advanced progress bar. This revolutionary new control can operate in one of two modes: Mode 1: Using standard .NET reflection as the input to a vast AI decision engine, the progress bar automatically determines exactly how long each task will take. This may also involve a certain amount of quantum mechanics and time travel, but let's not get into details. Suffice it to say that no matter how simple, complicated, or ridiculous the task, the progress bar will always move at a steady pace from 0% to 100%, reaching the latter exactly as the task completes. Mode 2: Every half-second, the bar randomly decides whether to stay still or advance a random amount. If it reaches the end, it stops at 99.9999% and shakes a little. And just to make it interesting, the bar randomly selects a mode when it's instantiated, and doesn't reveal that mode to the rest of the program. Can I patent this? :)
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
I think it's time for a more advanced progress bar. This revolutionary new control can operate in one of two modes: Mode 1: Using standard .NET reflection as the input to a vast AI decision engine, the progress bar automatically determines exactly how long each task will take. This may also involve a certain amount of quantum mechanics and time travel, but let's not get into details. Suffice it to say that no matter how simple, complicated, or ridiculous the task, the progress bar will always move at a steady pace from 0% to 100%, reaching the latter exactly as the task completes. Mode 2: Every half-second, the bar randomly decides whether to stay still or advance a random amount. If it reaches the end, it stops at 99.9999% and shakes a little. And just to make it interesting, the bar randomly selects a mode when it's instantiated, and doesn't reveal that mode to the rest of the program. Can I patent this? :)
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Ian Shlasko wrote:
This may also involve a certain amount of quantum mechanics and time travel, but let's not get into details
That's just an implementation problem.
Ian Shlasko wrote:
Can I patent this?
Not now you have published the idea here! :laugh:
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
Ian Shlasko wrote:
This may also involve a certain amount of quantum mechanics and time travel, but let's not get into details
That's just an implementation problem.
Ian Shlasko wrote:
Can I patent this?
Not now you have published the idea here! :laugh:
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
OriginalGriff wrote:
Not now you have published the idea here!
Curses! Foiled again! :-D
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
- Why would you make a progress bar that goes to 99% in 3 seconds, then stays there for 5 minutes? - Why would you make something that looks like a progress bar, but just runs back and forth in a container? - Why give me the illusion that this will be quick, then have me wait for 10 minues for that last %? Or worse, show me 100% for 10 minutes? - WHY? WHY? WHY? Make a progress bar that is usefull! Or don't make one! If it doesn't work, delete it, and replace with a loading animation that doesn't give false expectations. If you are a programmer, and made a crappy, misleading progress bar... I HATE YOU! :mad::mad: So, why are you releasing software with a feature that obviously doesn't work!? How f'ing hard is it to make one that works? If you can't, I think there's an opening there. *points you to mc donalds job board* If you're the manager that said "ok" to that, look here for an opening. *points to suicide booth* F F F F F FFS! #"%¤%! #&"¤"! There. I feel much better now. :-D
Have a 5. FoxPro would drive me mad doing that. I do not work with it now-a-days.
-
Technically speaking it is not the developer of the PB that sux but the one that decided to use it and it using it improperly that sux ;P Just saying. Also, I have been in the case where I had a nice even flow of progress. Then through some extending of the app the PB seems to hand (one end or the other.. Very rarely in the middle, although it happens as well). Take a File Reading process for example: Teh system first checks the count of files and then begings processing them, updating the PB as it finishes. But some nuckle head end user thought it would be a good idea to group 100K of his files into one file. Now the PB calculation is off because that one stupid file is actually 100K files worth of data. Granted, the developer could have checked the size etc. but then every EU has to wait longer because of that one stupid EU that thought it was a good idea to make such a large file. Again, just saying its not always the Devs fault. Deffinately it is rarely the PB devs fault. And often it is the systems fault for not being like the test system :-D
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
Collin Jasnoch wrote:
Technically speaking it is not the developer of the PB that sux but the one that decided to use it
Very often the one that decides to use it is the developer. Or, the person that doesn't convince the product owner not to use it, is the developer.
-
Collin Jasnoch wrote:
Technically speaking it is not the developer of the PB that sux but the one that decided to use it
Very often the one that decides to use it is the developer. Or, the person that doesn't convince the product owner not to use it, is the developer.
Hmmm, well when I whip quick apps together I use the out of the box MS one. Can't really blame MS for making a 'crappy' PB if it isn't responding. You can blame them for it looking crappy though ;P Otherwise, I think it really depends on the team size and application size. Most apps that I use I would bet this isn't true. The install package itself usually has its own team. And with in that team was the dev that made the PB. The install package has numerous components. Using my example above, it is possible that each component needs to stream a file. The PB dev can't help it if one of the teams made their file abnormally large.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
I think it's time for a more advanced progress bar. This revolutionary new control can operate in one of two modes: Mode 1: Using standard .NET reflection as the input to a vast AI decision engine, the progress bar automatically determines exactly how long each task will take. This may also involve a certain amount of quantum mechanics and time travel, but let's not get into details. Suffice it to say that no matter how simple, complicated, or ridiculous the task, the progress bar will always move at a steady pace from 0% to 100%, reaching the latter exactly as the task completes. Mode 2: Every half-second, the bar randomly decides whether to stay still or advance a random amount. If it reaches the end, it stops at 99.9999% and shakes a little. And just to make it interesting, the bar randomly selects a mode when it's instantiated, and doesn't reveal that mode to the rest of the program. Can I patent this? :)
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Ian Shlasko wrote:
Mode 2: Every half-second, the bar randomly decides whether to stay still or advance a random amount. If it reaches the end, it stops at 99.9999% and shakes a little.
I think this might require a warning. "May cause seizures" ;P I have seen games with this warning, but now not only would the game have the warning but the installer would! But on a possitive note, it would occupy the EU while installing :-D
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
- Why would you make a progress bar that goes to 99% in 3 seconds, then stays there for 5 minutes? - Why would you make something that looks like a progress bar, but just runs back and forth in a container? - Why give me the illusion that this will be quick, then have me wait for 10 minues for that last %? Or worse, show me 100% for 10 minutes? - WHY? WHY? WHY? Make a progress bar that is usefull! Or don't make one! If it doesn't work, delete it, and replace with a loading animation that doesn't give false expectations. If you are a programmer, and made a crappy, misleading progress bar... I HATE YOU! :mad::mad: So, why are you releasing software with a feature that obviously doesn't work!? How f'ing hard is it to make one that works? If you can't, I think there's an opening there. *points you to mc donalds job board* If you're the manager that said "ok" to that, look here for an opening. *points to suicide booth* F F F F F FFS! #"%¤%! #&"¤"! There. I feel much better now. :-D
I have done code reviews on file transfer routines that update the progress bar based on the number of files copied rather than the actual bytes transferred. So if there are 4 files to be transferred, the first three being 10 KB and the last one being 100 MB, this is what will happen.
-
I have done code reviews on file transfer routines that update the progress bar based on the number of files copied rather than the actual bytes transferred. So if there are 4 files to be transferred, the first three being 10 KB and the last one being 100 MB, this is what will happen.
Of course it's the programmer! Who else? And what is a "progress bar", if it gives no indication whatsoever about the "progress"!?!
