that's funny, I'm the other way around.. whenever I see syntactic sugar implemented via javascript, I unroll it in my head and consider it overhead, compared to sending a bunch of more bytes down the wire which hardly matter after gzip.
I tested infinite scrolling on a large site about a year ago and the results were decidedly negative in almost every significant respect according to our A/B testing. Does anybody actually have evidence that infinite scrolling is a good thing?
HN likes to pretend that infinite scrolling has no utility, but it's simply not true. For sites where you want to quickly scan a lot of content, infinite scrolling is vastly superior to static pagination. For sites where you will typically consume every item in the list carefully and want to refer back to specific points in the list, pagination is vastly superior to infinite scrolling. They both have their benefits.
The most significant loss is the ability to keep your place. Google Reader is a good example. There's no way to bookmark how far back you've read so when I reload or close the tab I usually have give up and abandon unread items.
You could mitigate this but it would be useful to see what benefits people think infinite scrolling introduces and (if there are any) see if there is a solution that gives the same benefits with fewer costs.
Maybe some hybrid 'paged' infinite scrolling where you can keep going but clear pagebreaks are displayed which are mirrored in the browser history.
Just a data point, I find lightbox (photo sharing site, not js lib) to be so incredibly addictive that I spent 1/2 hour on it. There's no way I would have spent more than 5 mins had I have to click on each page.
Pinterest seems like the best example. I don't have any numbers but explosive growth and fanatical users seem to be good circumstantial evidence for infinite scrolling. Prismatic also uses it and personally I love it on that site.
Personally I like infinite scrolling on a website like http://pr0gramm.com (warning: contains some explicit imagery, so NSFW)
I just check it out once every 2 or 3 days for a quick laugh and eventually I stumble upon some images I've already seen, which is when I close the site.
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
Script: https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js:4
On:
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
Script: http://airbnb.github.com/infinity/infinity.js:154
Same here, but I wouldn't expect much from a jQuery plugin that implements "infinite scroll". Like I need stuff to start loading by itself whenever I reach the bottom of the page.
Also, looking at their code, the first thing I laid eyes on was this statement:
var infinity = window.infinity = {};
Which, in this context, would be the exact same as
I tried both off and on demos, and all I got was a huge page loading slowly with scrolling causing flickering and stuttering. This is on Linux/Chrome. Maybe people shouldn't try to create large, image heavy pages in the first place, not to mention make them infinitely long.
Yeah, Mac/FireFox here and the same experience. both the on and off demos gave me a spinning beach ball for a minute while what seemed like the entirety of the content loaded. I thought that's what infinite scrolling was supposed to prevent?
UITableView was made for mobile devices not for infinite scrolling per se, but simply for large lists (such as address books) due to the memory limitations of iOS devices.
Those memory limitations are simply nonexistent for the web for almost all but the smallest number of cases (ie, infinite lists).
But lets pretend that this infinite scrolling is even a real problem (honestly it's probably not the best UI for large infinite lists of things on the web).
The current implementation clearly needs some work. It's trying to over-optimize for memory to the point of choking the scrolling.
This, however, can be fixed fairly trivially.
Allow the user to scroll anywhere (even past loaded content). If you can't eagerload elements to compensate for it, then lazyload after the user gets to that point. This gives users the illusion that the scrolling is truly smooth and responsive. The important thing is never allow scrolling to stop unless it's truly at a dead end and there is absolutely no more elements to load.
The above is how UITableView functions. Infinity.js is UITableView for loading elements, but does not function anything like UITableView from a user interaction standpoint.
Author here. The utility is just to improve scroll smoothness (aka repaint times) of very-expensive-to-render pages, like infinite feeds with nice CSS effects. If you check out the demos linked to on the page, the demo with Infinity turned off should be noticeably choppier than the demo with it on, even once it's completely loaded and the browser's stopped reflowing. Probably depends on your machine/OS/browser combination -- but it'll keep loading more pugs as you scroll down, and eventually the version with Infinity off will grind just about anything to a halt.
"UITableView for the web" … what does that mean? Why should a web dev know or care?
Make "demo" not "on" and "off" prominent. That's what I'm scanning the page for. Especially if you say "Infinity on and off" and it's the first time you use the word Infinity at all. Use Infinity or the symbol and then stick to it. At least introduce the name first.
Hm, it doesn't degrade very well without javascript on (pagination would be a neat fallback). I know it's not generally worthwhile to cater to such a limited user population, but what about search engines? Should this only be used for content you don't need indexed, or you have indexed a different way?
Or, since I think Google uses javascript in its crawlers, I wonder how it handles it. Presumably it would just keep scrolling until the content ran out or it gave up. But does it ever come back later? I know with pagination it could pick up on the links it left off on, but couldn't really do that here, right?
edit: I guess this is really a question of infinite scrolling more than this particular implementation. Kudos to Dropbox for releasing a well-done version of the technique.
True fact. That's just due to scrolling fast enough to get outside the buffer before the throttled scroll event fires -- if you want, you can turn the scroll throttle down to make sure that doesn't happen, at the expense of doing slightly more computation while scrolling. For Wish Lists, we optimize for people browsing through the feeds, which is generally not super fast. :)
We (at our company) don't use pagination anywhere now. But we do have extensive search abilities. We have found, very few of our users just scroll. They use the search. But the "infinite" scrolling is there if they want it.
[+] [-] threepointone|13 years ago|reply
for(var index = 0, length = listItems.length; index < length; index++) { listItems[index].remove(); }
and I think to myself -
_(listItems).invoke('remove')
[+] [-] zaptheimpaler|13 years ago|reply
[+] [-] quarterto|13 years ago|reply
[+] [-] Kiro|13 years ago|reply
[+] [-] thinkingisfun|13 years ago|reply
[+] [-] whirlycott1|13 years ago|reply
[+] [-] marknutter|13 years ago|reply
[+] [-] andybak|13 years ago|reply
You could mitigate this but it would be useful to see what benefits people think infinite scrolling introduces and (if there are any) see if there is a solution that gives the same benefits with fewer costs.
Maybe some hybrid 'paged' infinite scrolling where you can keep going but clear pagebreaks are displayed which are mirrored in the browser history.
[+] [-] fuzzythinker|13 years ago|reply
[+] [-] zzzmarcus|13 years ago|reply
[+] [-] wsc981|13 years ago|reply
I just check it out once every 2 or 3 days for a quick laugh and eventually I stumble upon some images I've already seen, which is when I close the site.
[+] [-] _lj|13 years ago|reply
[+] [-] debacle|13 years ago|reply
[+] [-] ars|13 years ago|reply
I have noscript installed, but all scripts on that page were allowed.
[+] [-] brokenparser|13 years ago|reply
Off:
On: Firefox 14.0.1 without NoScript, Linux 3.4.0.[+] [-] gilini|13 years ago|reply
Also, looking at their code, the first thing I laid eyes on was this statement:
Which, in this context, would be the exact same as[+] [-] bicknergseng|13 years ago|reply
Don't have a footer. Example of this error: LinkedIn. Try to get to their ToS or Help Center from the logged in home page. Good luck.
[+] [-] fuzzythinker|13 years ago|reply
[+] [-] yason|13 years ago|reply
[+] [-] notatoad|13 years ago|reply
[+] [-] weixiyen|13 years ago|reply
Those memory limitations are simply nonexistent for the web for almost all but the smallest number of cases (ie, infinite lists).
But lets pretend that this infinite scrolling is even a real problem (honestly it's probably not the best UI for large infinite lists of things on the web).
The current implementation clearly needs some work. It's trying to over-optimize for memory to the point of choking the scrolling.
This, however, can be fixed fairly trivially.
Allow the user to scroll anywhere (even past loaded content). If you can't eagerload elements to compensate for it, then lazyload after the user gets to that point. This gives users the illusion that the scrolling is truly smooth and responsive. The important thing is never allow scrolling to stop unless it's truly at a dead end and there is absolutely no more elements to load.
The above is how UITableView functions. Infinity.js is UITableView for loading elements, but does not function anything like UITableView from a user interaction standpoint.
[+] [-] pokoleo|13 years ago|reply
[+] [-] reissbaker|13 years ago|reply
[+] [-] Schlaefer|13 years ago|reply
"UITableView for the web" … what does that mean? Why should a web dev know or care?
Make "demo" not "on" and "off" prominent. That's what I'm scanning the page for. Especially if you say "Infinity on and off" and it's the first time you use the word Infinity at all. Use Infinity or the symbol and then stick to it. At least introduce the name first.
[+] [-] AlexCP|13 years ago|reply
[+] [-] losvedir|13 years ago|reply
Or, since I think Google uses javascript in its crawlers, I wonder how it handles it. Presumably it would just keep scrolling until the content ran out or it gave up. But does it ever come back later? I know with pagination it could pick up on the links it left off on, but couldn't really do that here, right?
edit: I guess this is really a question of infinite scrolling more than this particular implementation. Kudos to Dropbox for releasing a well-done version of the technique.
[+] [-] tantalor|13 years ago|reply
[+] [-] lucian1900|13 years ago|reply
[+] [-] devgutt|13 years ago|reply
[+] [-] jazzychad|13 years ago|reply
[+] [-] SeckinJohn|13 years ago|reply
[+] [-] reissbaker|13 years ago|reply
[+] [-] crag|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] humbyvaldes|13 years ago|reply
[+] [-] gamzer|13 years ago|reply
[+] [-] shocks|13 years ago|reply
[+] [-] frontendbeauty|13 years ago|reply
[+] [-] lowglow|13 years ago|reply
[+] [-] dotborg|13 years ago|reply
[+] [-] shmageggy|13 years ago|reply