Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Spin.js, a pure JS spinner

fgnass.github.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Spin.js, a pure JS spinner

#51

Post by alanh »

eelco wrote: post #50
alanh wrote: post #43

Earlier quoted context omitted.

If you want to show actual progress and have actual data indicating progress, there are much better ways to show it. - 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 completely agree with you, but the user might have been trained by his iPhone to relate the speed of the spinner to the data transfer speed. (The spinner in the status bar of the iPhone indicating network activity has a different speed when you're on EDGE or GPRS versus when you're on 3G).

You raise an interesting point. That throbber does have (exactly) two speeds — but if you are experiencing EDGE-speed transfer rates over 3G for some reason (low connectivity), it still spins at the normal (3G) speed. So it’s not quite the same as what’s being suggested here, as I understand it (a variable speed throbber tied to current transfer rates). Certainly an intriguing design decision though.

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.

Re: Spin.js, a pure JS spinner

#54

Post by r00fus »

jsdalton wrote: post #2

I think the possibility of dynamically changing the speed of the spinner is interesting. If your spinner was representing a file upload, for example, you could conceivably adjust the speed based on the current upload rate.

Isn't this similar to how the iOS "download" meter shows network rate?

Re: Spin.js, a pure JS spinner

#56

Post by beernutz »

gregory80 wrote: post #41
dw0rm wrote: post #22

Are there any GIF loader generators that have all this options (speed, sizes, color) available? Could be good to use this as a preview, and then generate the final GIF.

I'm a fan of http://preloaders.net/

That site is awesome! Very nicely laid out.

Re: Spin.js, a pure JS spinner

#57

Post by uast23 »

Read through quickly at first and got mislead by 'target' assuming that anything passed as a target will start spinning and tried to spin an image :), which of course is not the case. Nice effort though.

Re: Spin.js, a pure JS spinner

#58

Post by jabkobob »

Nycto wrote: post #3

A spinner generated from http://www.ajaxload.info/ is 673 bytes. The minified javascript from this is ~3K. I suppose the trade off is features and flexibility, but I don't find myself needing much out of my ajax spinners.

But the ajaxload spinner is evil and they still haven't fixed it! http://www.panic.com/blog/2010/10/spinner-rage/

Re: Spin.js, a pure JS spinner

#59

Post by user24 »

jabkobob wrote: post #58
Nycto wrote: post #3

A spinner generated from http://www.ajaxload.info/ is 673 bytes. The minified javascript from this is ~3K. I suppose the trade off is features and flexibility, but I don't find myself needing much out of my ajax spinners.

But the ajaxload spinner is evil and they still haven't fixed it! http://www.panic.com/blog/2010/10/spinner-rage/

of all the things to get het up about...

Re: Spin.js, a pure JS spinner

#60

Post by user24 »

hasenj wrote: post #29
pharrington wrote: post #18

Earlier quoted context omitted.

I accidentally upvoted you (trying to view your profile, I dont have downvote privileges). The CPU use of just about any GIF spinner is trivial compared to this, even in the browser this runs best in. Sure its a solid enough concept , but not something that'd you actually use in practice yet.

I actually agree that a JS spinner probably uses too much CPU to be justify its use, but I seriously doubt it would have that much effect on the battery. EDIT: It also seems the actual spinning is done with CSS, not JS

> 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.

Post reply on HN