I've never been a huge fan of the whole 'infinite scrolling' pattern, largely because there are so many ways to implement it wrongly, and so many implementations seem to screw it up.
Consider the following use cases, both of which I've experienced, and the expected behavior that would occur on a normal paginated implementation:
You're on a site with infinite scrolling, and decide to click on a link within a post that's several pages down. The website's maintainers didn't add a 'target' attribute to links so that they'll open in a separate window, so the link you clicked on takes over the window. You have to click your browser's 'back' button to return to the page you were just viewing.
Expected behavior: When you click 'back', you'll be returned to the post you had just been viewing.
You're using a public Wi-Fi connection that's a bit overloaded by all the other users on the same network. The connection often ends up timing out before web pages finish loading, and it's frequently necessary to reload the page several times until all of the content manages to load.
Expected behavior: When you reload the page, you'll be returned to the same general set of posts where you had been before reloading.
The question, then, is: if your site uses infinite scrolling, does it produce the expected behavior in these scenarios?
With LiveJournal's new friends page beta, the answer is a resounding NO.
The first scenario happens to produce the expected behavior in Firefox...but strictly as a lucky side effect of the way that Firefox caches pages in memory. If the page ends up getting flushed from the memory cache, however, you're sent all the way back up to the first page of posts. This same scenario also fails unconditionally in Chrome, which handles caching of dynamic content differently.
Given that even comments pages open in the same window by default? This...is a problem.
As for the second scenario, LJ's implementation is particularly problematic when you're on an unstable internet connection. When the page is refreshed, you're immediately returned to the absolute most recent post, with none of the additional pages loaded. So, if it was the fifth page of results that failed to load, you'll have to scroll all the way back through the first four pages again. And if one of those fails to load instead, you have to hit reload again, and...well, you get the picture.
For goodness' sake. Even Tumblr has a better implementation of infinite scrolling than this, if only slightly--and for those of us who still find it frustrating, they also offer an option to disable that 'feature' entirely on the user preferences page.
Somehow, LJ has managed to be worse than Tumblr in their implementation of this feature. And given how many bugs I've found in Tumblr just from my everyday use of the site? That's really saying something.
This entry was originally posted at
http://codeman38.dreamwidth.org/4979.html.