Monday June 01, 2009 at 19:00
Subject: More information about change in a progress bar.
Keywords:
GUI, Ideas
Posted by: Sean Reifschneider
One thing that progress bars don't tell you very well is when
something has changed and by how much. You can see the overall progress,
but if it's stalled and you look at it, you just can't tell if it's made
any progress recently... Unless you watch it VERY closely.
I have an idea on this front... Make the progress-bar be in two
colors and when the progress changes draw it in one of the colors. Then
as time goes on fade the one color into the other. The overall effect
would be similar to those progress-bars that are just a gradient, but with
the gradient actually meaning something.
So you could look at it and if it was all the "old" color you'd know
it has been stalled for a while with no progress. If it's all the "old"
color with a chunk of the "new" color at the end you'd know that it
was stalled but got some more information recently. If there are three
different chunks of progressively faded color at the end, you'd know the
relative age and size of the last 3 updates, etc...
Now somebody just has to implement it. Unless it's already
implemented, in which case I've never seen it...
(Post Reply)
(Post Reply)
| Comment |
Lucia Subject: Your point is...? |
What would be the usefulness of this? Just so hysterical users can click ten times per second everywhere on the screen, surely hitting buttons, therefore increasing response time even more? IT is about algorithms, math, algebra, not about 'slick' or 'quick'. If for whatever reason you or your users feel something takes too long to complete, then refine your code or buy faster hardware but this kind of information overload is pointless and leads nowhere.
Oh, yeah, I was forgetting: Vista will sooner or later do this, so obvioulsy everyone needs it too to stay competitive!
| Comment |
Author:
Sean Reifschneider Subject: Ok, smart guy... |
The use-case that made me think of this was the progress bar on my Android phone while uploading an image over the cellular network in a location with not the best coverage. So after a minute I looked at it and it was, say, 70% complete, but unless I paid fairly close attention to it for a while to see if it moved, I couldn't tell if it was stalled or not...
So, there aren't really hardware or algorithm changes that could solve this. Becoming a CLEC and setting up a phone company to provide really good coverage for this area I was in is also not a realistic option.
I hear your point about not wasting the users time with extra bells and whistles. However, you seem to have completely missed my point that it's not good to waste the users attention by making them stare at a progress bar for 30 seconds to see if it's moving or not. I proposed a simple change that could make progress bars convey much additional information without overwhelming the user and still being readable at a glance, even for very thin progress bars (in this application the bar is 4 or 5 pixels high, not really enough to include a "50% done" label in...
Sean
| Comment |
Lucia Subject: Better representations |
Ok, I was picturing that progress bar in a desktop OS and I thought 'WTF cut the eye candy already'. Now that you say it's a phone, well, the information presented by a progress bar is one dimensional: a single number, and it's not the best representation to build on it to present information in a time domain. In fact you have to add that dimension of time by 'looking closely'. My preference would be a number: time to completion, as it factors speed in and if the phone shows you infinity you know it's stalled without squinting at a 4 wide pixel bar for several seconds. Also take into account things like driving or not paying complete attention to the phone, or the glare of the sun. I'd definitely go with ETA and nothing else.
| Comment |
Author:
Sean Reifschneider Subject: Yeah, that seems reasonable... |
Yeah, a time to completion seems more reasonable, but would require more "height" than we are giving the progress bar now. With just the ETC and no progress bar, it would be less overall screen space though... So it's a trade-off.
Sean
| Comment |
Brian Cairns Subject: Byte counter |
What you really want is a byte counter. My old Treo 650 had a byte counter in the browser and it really helped to let you know that something was actually happening.
What pisses me off is that GUIs these days will often use GiB when transferring large files, but they use some ridiculously-low level precision (like 4.5GiB remaining). 100MB takes at least 40 seconds over my wireless connection, so it's hard to tell whether I'm actually moving data or if the link has gone dead.
The Sidekick had a little tower icon that animated when data was being transferred, which worked pretty well too. It also helped that you could hear the "GPRS buzz" through the poorly shielded speakers.
| Comment |
Author:
Sean Reifschneider Subject: Byte counter still requires watching... |
The byte counter still needs you to watch it to see if it's making
progress, particularly, as you say, if it is fairly coarse-grained.
Plus, the numbers need to be quite a bit bigger than 4 pixels high --
which can be an acceptable progress bar height...
Really, it's all about providing both the odometer (percent complete)
and speedometer (current speed). But with the "fading" idea you can get
an idea of the speed of the last N samples. This is kind of the motion you
would get on an analog speedometer, telling you the trend, but at a glance.
For example:
The top progress bar shows at a glance a download that is around 80%
done, going at a fairly constant rate, and will be done in, say, the next
few seconds.
The lower bar shows also around 80% done, but is slowing down and will
take at least another 5 seconds, probably longer with the current trend...
The top progress bar shows at a glance a download that is around 80%
done, going at a fairly constant rate, and will be done in, say, the next
few seconds.
The lower bar shows also around 80% done, but is slowing down and will
take at least another 5 seconds, probably longer with the current trend...