In the comments someone trotted out an example of his own automatic infinite scroll that he felt was effective and was developed with the user in mind. I got a bit ranty and suggested otherwise. That wasn’t as productive as it could be, partly because I was commenting on one example that other developers might feel doesn’t apply to their own efforts at similar implementations.
I think maybe this could all be made a bit easier by offering a quick checklist of what to test, expect, and review if you attempt your own version of an automatic infinite scroll. Here is my attempt at one, but please feel free to suggest others (or corrections) in the comments below.
1. Can the user hit “back” and return to the exact same place?
There’s nothing quite so infuriating as loading a few screenfuls of content, following a link, and then coming back only to find you have to reload those screenfuls of content all over again. Not only is it a waste of time, it’s a waste of bandwidth.
3. Does the page have a footer?
Now you’re just being a tease. The user will never get there, so don’t lie by showing the footer and implying he or she can get there. You might as well just remove it. It’s at least honest.
4. Can a keyboard user access all other content on the page?
Unless the content that keeps updating is (or contains) the last focus-able element in the source order (the linearized version of your page), then a keyboard user (as well as screen reader users) will never be able to get to that content. Just like the footer you might as well remove it altogether.
5. Can you share a URL to a specific place on the page?
After you’ve gone a few screenfuls deep you may have found a few links of interest. Can you copy the address from the browser and email it (or even tweet it) and expect the recipient will come to exact state of the page (a few screenfuls in and with that content visible in the viewport)? Remember, an anchor is useless if it hasn’t loaded yet (or has been co-opted by your script).
6. Can a user easily jump ahead a few “pages” to quickly get to content much further down the list?
Consider a list of news. After a couple screenfuls you might glean that each screen loads a week (or a month or whatever time period). You want content from a few weeks ago (or a few time periods ago). In a traditional paged navigation you could jump ahead a few screens to more quickly get further down the timeline. If your approach doesn’t afford users this control, you’re wasting your users’ time and bandwidth.
7. Does the memory footprint of the page dramatically increase after just a couple new “pages?”
Keep your favorite memory monitoring tool open and load a few screenfuls. Then a few more. Then perhaps all. Take a look at how much memory this requires and then compare to available memory on other devices (such as smart phones). Remember that a mobile browser may reclaim memory by dumping other resources from working memory, potentially purging the rest of your site and its assets from the user’s cache, resulting in more bandwidth overhead and longer download times on subsequent pages.
8. Is there a way to disable automatic infinite scrolling and lean on standard paging?
Can the user easily disable the infinite scroll? Forget browser configuration acrobatics, instead look for a very visible single-click/tap option for the user to disable infinite scrolling and move on.
9. Have you conducted any user tests?
Before you roll this out, make sure some real users sit down in front of it. Nobody from your organization. Nobody who is an IT professional, developer, or whose paycheck depends on making you or your boss happy.
10. Are you satisfying a use case that has come from research or user request?
Did this feature request come from users, or the client? Or your boss? Or your desire to flex your scripting muscles? If you don’t have a compelling use case or feature request to add it, you may want to put your efforts toward features that truly have value, like print styles.
11. Do you have any analytics/tracking to measure success?
If you do decide to launch your perfect automatic infinite scroll feature, don’t forget to put some tracking scripts in place to determine how many screens deep your users go, and how often they click. There are other things you can measure (like if the footer ever gets clicks on that page). After all, success isn’t measured by you launching, but by whether or not it works well.
Update: July 14, 2014
Remember the example site from my infinite scroll post? Site now does two-screen-at-a-time-only scroll: http://t.co/5bv9ogogd8
1. The back button doesn't apply as all links open in a new window, so kudos for bypassing that one.
3. There is no footer, so you PASS #3.
4. As I tab through the page, partway into a second post my keyboard focus jumps back to the first post. Consistently (Chrome 35 Win). It fails #4.
5. I cannot share a URL, though that point may not apply as this is a page behind a login.
6. I cannot jump ahead a few screenfuls, so it fails #6.
7. I only loaded about 20 items, but the memory did increase and will do so even more for longer blog entries. I say it fails #7.
8. I see no option to disable the auto infinite scroll. It fails #8.
9. Have you conducted user tests?
10. Was this feature driven by a clear need or request?
11. Are you measuring (not just tracking) how well this works for users?
Out of 11 items, it passes only 1. Your example fails 5, doesn't apply to 2 more, and the remaining 3 only you know the answer.
I don't consider a ~50% failure rate (or ~10% pass rate) something that covers "a lot" from my checklist.
I'm not sure why you posted it. It's a pretty quick process for you to check it and you have to see it doesn't pass any more than one item, Four items (out of eleven) if you can make a case for your user testing.
I opted not to use a list at all because with the amount of content I figured headings were an appropriate fit (though I did consider an opening list with anchor links to each heading). Ate you suggesting I wrap the entire post in an OL and put headings/content in each LI?