Spin.js, a pure JS spinner
fgnass.github.com
fgnass.github.com
I'm on Chromium 12 on a Fedora 15 box. Top reports ~25% (on a dual core Arrandale, so that's about 1/8th the available CPU time), but checking the clocks more carefully shows that they're spending half their time in sleep states and never moving from the 1.2GHz base speed (this model turbos at 2.9GHz). So my envelope tells me this is about 4-5% usage vs. a fully loaded system.
Explorer is better than Firefox and Opera, but still pretty high CPU usage.
The only browser of the ones I tested that it seems to be relatively fine in is Chrome.
And just because why not:
IE 8 in a winXP vm: 0%
IE 6 in a winXP vm: 0%
Doesn't work in FF3.
<input type="range" min="0" max="100">
<input type="number" min="0" max="100">
It's the difference between "cool, it works" and "wow, this is elegant and beautiful" - the Apple effect, if you will.
Says who? I think progress indicators are intended to communicate more-granular details about the true progress towards some goal ... hence their name.
It's a scam. It's a nice scam, of course, since it makes computers seem faster, and that's most of what really matters, but a scam nonetheless.
But I don't think I've said progress bars are bad. They're useful! It's just the idea of "maybe we can make progress indicators more accurate" that's ridiculous.
But that's not bad. I said it was a nice scam. Sometimes it's good to be fooled. Putting a minigame during the load screen doesn't make the real game load any faster, but it makes the time seem to pass faster, and that's nice. Doesn't make it not fooling.
As for streaming video, as I said already, a video buffer indicator is tied to a UI element in the timeline. It tells me where I can scrub to in the timeline and have it play video immediately without buffering. That's useful.
It's not useful as a progress indicator, for telling me how much longer I need to wait to watch the video-- because my computer is way, way better at doing that math than I am. I would much rather have a simple indicator that tells me, given my current download speed, whether I will have to wait for buffering before it finishes playing, and if so, how long I have to wait until that is not the case. In fairness, you can get a decent idea of that based on whether or not the buffer indicator is advancing away from the playhead, which is another detail that distinguishes a streaming buffer from other sorts of progress indicators.
Now do that with a progress bar. You can't. What do you do, hold a piece of paper under the bar and fold it in half? Then guess whether the bar is measuring estimated time to completion, percent of data transferred, or percent of files transferred?
You can ballpark it at a glance, sure. It's obviously under a quarter done. Obviously over a tenth. Is it under a fifth? Maybe. We're just not good at judging those things. And progress animations are deliberately designed to make it even harder.
And don't get me wrong-- it's nice to be able to ballpark it at a glance. It reassures me that it's moving at all. It gives me some idea of how much longer it will take. It makes it seem like it's going faster. That's what I'm saying.
- Progress bar. Indicates estimated percent completed at a glance. Perfect for uploads/downloads where file size and progress is known.
- Text and/or line/sparkline graph. If you only know speed, this is how to show it.
How is the user supposed to know spin rate means anything?
I have to imagine the slow speed of the EDGE throbber is saying, “Expect this to take awhile. Look, I take 6 seconds to even spin around once…”
Thus if we were to take the concept to the Web, it might make more sense to tie rate of revolution not to speed, but rather to expected time to complete (based on speed and file size) such that we expect the spinner to make exactly (say) 15 revolutions before the upload completes (with a min and max cap on revolution speed, of course).
I still maintain that if we know this much information, though, we ought to just show a progress bar and optionally text as well.
Especially not as I'm actually using Safari 5.1.
http://www.loadinfo.net/ is much better presented and actually respects the color values you type in! (And no, I don't have any relationship with them.)
EDIT:
It also seems the actual spinning is done with CSS, not JS
that means it'll be hardware accelerated where supported, which will increase battery life.
I wonder if this could happen in a regular browser, too?
I have a hunch that’s correct, but don’t know.
I do however have an unanswered question on Stack Overflow seeking, ideally, a generator of JavaScript + PNG throbbers. First one to make ajaxload.info with PNG sprites and/or Canvas generation in supported browsers wins! (No need for most of the hideous ajaxload designs though.) http://stackoverflow.com/questions/6937149/best-practice-too...
It was spinning very slowly, but the Mango update supports CSS3 well it seems.
Independent.