The Interaction Design Pattern
Infinite scroll has been called autopagerize, unpaginate, endless pages. But essentially it is pre-fetching content from a subsequent page and adding it directly to the user’s current page.
Problem Summary:
User is browsing paged content.
Use When:
- Retaining the user is important and clicking “Next Page” is a usability barrier.
- The full content available is too large to show on initial load.
- The content is available in paged chunks: search results, blog posts, product listings portfolio features.
Advantages:
- Users are retained on the site far better.
- Users are less likely to continue on to the next “page” if they have to click something versus it being delivered automatically to them. [citation needed]
- Requires no adjustment in a user’s typical reading habits.
- The added functionality needs no affordances or instruction.
- As long as the functionality is enhancing an existing navigational structure (like the wordpress plugin here), it remains SEO-friendly and Accessible. It will degrade gracefully if a user does not have JavaScript enabled..
Disadvantages:
- The “footer” of the page will be typically impossible to reach.
- Currently there is no way to cancel or opt-out of the behavior.
- There is no permalink to a given state of the page.
- Dynamically adding more content to the page increases the memory footprint of the browser. Depending on the browser, this could account for around 50megs of RAM.
- Analytics will not immediately capture the event, so custom configuration is required.
Implementation Recommendations:
- Depending on site latency, new content can be fetched aggressively (when a user has 500px of the page left to scroll) versus at the last moment (with ~100px left).
- User should be notified when there is no more content available.
- Consider a faux pagination widget to allow for navigation within the new content. Travis Isaacs has ideas on a running pagination.
- Infinite scroll should be implemented as progressive enhancement. Typical navigation/pagination should be present for users with javascript disabled. Javascript-enabled users, however, will experience the more rich reading functionality.
Examples in the wild:
- Humanized Reader
- SocialThing
- Live.com Image Search
- Soup tumblelogs
- Google Reader, Yahoo Mail use the same technique but within a container
2 comments.
I couldn’t agree more with the philosophy here. At work, we have a lot of paging, and moving forward I want to try to institute something like this, however - I have one lingering question: What to do to manage memory growth? There comes a point in instantiating objects, lets say, each post is a new element - when this continually grows - your reference count also grows. What if the scrolling is on the order of hundreds of items?
I only had one initial idea, which was to remove references to posts that are within a certain limit, like 100 items previous. Then, re-initiate the gets for those hundred if the user scrolls up, and do the same thing going down.
Essentially you would have a window of, for example, 100 items in the viewport above your viewing area, and potentially 100 items below your viewing area (if the user had scrolled back up). Beyond that references are removed, or objects/DOM is emptied.
Any other ideas on a viable solution to the scalability of this? Anything is appreciated. Thanks! http://theuiguy.blogspot.com
Yeah I’ve noticed this myself. I run it on my mp3 blog Aurgasm and a few people have mentioned growing memory use. So I agree this isn’t scalable for a rich media site that has >100 pages, but really I don’t know what that upper bound is.
Perhaps it doesnt trash the content 100 items (or whatever) ago, but instead stores the innerHTML in a javascript object, it would certainly be a hugely reduced memory footprint. One i wouldn’t be worried about.
This does deserve some more thought. Thanks for sharing yours.