21–30 of 30 posts
And I'll throw in this one just because it's funny (and quite on-topic): http://xkcd.com/612/
Irrelevant Digression: The niftiest progress bar I've ever seen wasn't a progress bar. It was a little morality play. As the game installed a dinosaur slowly bounced across the installer window and _ate_ a hapless user .. who didn't send in his registration card. Still remember that, seventeen years later.
Unfortunately, Atari owns a patent on little games loaded for someone to play while a larger bit of data is being loaded.
Pity. If Oracle has wee little cartoon dinosaur mayhem I'd be a happier guy.
Earlier quoted context omitted.
What, seriously?? How the hell can you patent that??
I would love to see that patent. I have a hard time imagining it would be enforceable.
It's actually issued to Namco, but it seems to describe exactly that.
I think I have a PSOne Namco game with a preloader, possibly Tekken. I never so much as dreamed that was patented, though.
Two things I've half seriously considered if I ever need to do a progress bar: 1. Make the errors amusing to the user. For instance, if the operation goes over the estimate, go ahead and fill the progress bar to 100%. Then pause a second, and act embarrassed. Change the progress text to something like "Uhm...err...well, this is a bit embarrassing...", then go one to explain it's taking a little longer then expected.…
For bonus points, display the underlying data in some way so that I can draw my own conclusions, supplanted with "sidechannel" information I am likely to have, e.g. previous experience with the process if nothing else. Extra bonus points if you make this information optionally visible so that I can tune it out if I don't need it and my mom doesn't get confused. I really like modern copy dialogs in that regard (and not-so-modern ones on decent file managers).
If you can't make the estimate reasonable at all, don't make a progress bar and display progress in some other manner instead. E.g. if you are copying files, and you have no way of knowing how large each file is, consider simply putting down a simple count ("Files copied: x/y") and if at all possible some indication that the program is progressing at all ("Current speed: x MB/s").
Finally, please do try to add some kind of progress information for any task that can take more than a few seconds. It's incredibly frustrating to stare at a "busy" mouse pointer[1], having to guess whether an application has locked up or if it's just taking extremely long. If you get it wrong, you usually end up re-trying and being faced with the same situation. I have had to play detective around applications misbehaving that way, and having to use top, iotop, etc. to determine whether an app is using CPU, hard disk or network resources is both a lot of work and non-conclusive (not to mention beyond the capabilities of most users).
(This started out as a short reply and ended up quite being a more general rant; the second time this has happened to me tonight. Sorry about that.)
[1] Though terminal utilities are often just as bad, because they're not just designed with interactive usage in mind. However, each individual terminal utility tends to do less, which means complex process are broken down anyway, which yields some progress information.
Irrelevant Digression: The niftiest progress bar I've ever seen wasn't a progress bar. It was a little morality play. As the game installed a dinosaur slowly bounced across the installer window and _ate_ a hapless user .. who didn't send in his registration card. Still remember that, seventeen years later.
Unfortunately, Atari owns a patent on little games loaded for someone to play while a larger bit of data is being loaded.
It seems to me that a modern operating system, which might be used on several different networks throughout the day, and which may offer a variety of different hardware configurations, should be able to provide information to applications which could be useful in calculating this sort of thing. Things like latency, typical data throughput (network and local storage), etc.
Earlier quoted context omitted.
I would love to see that patent. I have a hard time imagining it would be enforceable.
It's probably this: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sec... It's actually issued to Namco, but it seems to describe exactly that. I think I have a PSOne Namco game with a preloader, possibly Tekken. I never so much as dreamed that was patented, though.
The file download was a bad example. I understand the file download progress bar to mean how much of the file I have downloaded. No more, no less. Next to that progress bar is the current rate and an estimate of the remaining time. This is not what frustrates me. What frustrates me is a progress bar for an installation task that sits at 99% or 100% for about the same amount of time it took to get there in the first p…
The mapper example is actually particularly pertinent. Hadoop's GUI shows me the progress of my M/R jobs with a bar, but it is as dependent on the amount of other tasks running on the cluster as downloading a file is dependent on the traffic in the network. There is no sane way to accurately estimate the amount of time a M/R job is going to take a priori, as far as I know. A stochastic method would be too variable and a method playing clever tricks with psychology seems especially insidious, from an engineer's perspective. You might as well replace it with an "Are we there yet?" button that responds to you in a soothing voice "Not much longer now".