The UX of Infinite Scroll: The Good, the Bad, and the Maybe

Before we delve into the pros and cons of “infinite scroll”, I guess we should first come to consensus as to its definition. I say this because when I was first tasked with writing this article I began to write about my idea of infinite scroll, which was the “One Page Site” where all of the site’s content resides in the home page and the navigation links point to bookmarks within the page.

This was not the definition that my counterpart had. It’s a likely candidate for multiple concepts of what it means.

For the purposes of this article the definition of infinite scroll will be:

A design pattern where content is fetched asynchronously from a database or master file and inserted into the user’s page as they consume the information. This results in a seemingly endless page that continues to load content as the user scrolls towards the bottom.

Here are a few examples

• White Men Wearing Google Glass (all tumblrs for that matter)
• SocialThing
• Live.com Image Search (Started using it September 17th of 2006!)
• Soup tumblelogs

Like almost any major design pattern, it’s neither good nor bad, in and of itself.
It’s up to us as designers and developers to apply our logic, experience, and foresight in order to include or exclude it from our projects on a case by case basis.

Make no mistake; Infinite Scroll is definitely a major design pattern – the site that bears its name ( Infinite-Scroll.com) has been around since 2008 according to Netcraft:

Now that we’ve established a common definition and gotten the preamble out of the way; let’s dive right in and take a look at both the good and the bad.

The Good

• You stand a better chance of retaining the user because there’s nothing for them to do but scroll. It’s almost like a subliminal call to action.
• There’s no necessity to instruct the user. If they’re on the page we can safely assume that they at least know how to scroll.
• The reading style/habit of the user will likely be compatible with Infinite Scroll.
• Infinite-scroll.com claims that when used correctly (like with their WordPress plug-in), navigation is enhanced, SEO is unharmed, and accessibility is maintained, as well as graceful degradation in finicky browsers and/or when JavaScript is turned off.
• Not using the WordPress plug-in? Here’s a good article about SEO friendly Infinite Scroll: https://www.sitepoint.com/seo-friendly-infinite-scroll/
• It’s relatively easy toimplement in most projects, with a simple jQuery plug-in.
• You can reduce page load size, but usually savings are compared to a page you wouldn’t make unless there was a solution like Infinite Scroll to tame it…

Example: Facebook.com

Let’s take a look at an infinite scroll that I think is well-executed.

We can assume that Facebook can afford to have a few people thinking about nothing but their UI. They use Infinite Scroll on several of their content types, and they’re not just doing it because it’s cool. To their credit, many of the negatives listed in the next section don’t factor into their use of the technique. For instance, each “story” in the newsfeed is basically a blurb or teaser designed to get the user to view it, like it, comment on it, or share it to their own timeline.

It seems obvious that the users have been trained, if even unconsciously; if they don’t want to get lost in Infinite Scroll’s hassle of getting back to a segment of the page, they better interact with the content as soon as they see it. In this way it seems that Facebook has used one of Infinite Scroll’s detriments to boost user interaction.

I know from personal experience that if I see something in my newsfeed that I may want to re-visit later I’ll share it so that I can find it easily in my own newsfeed.

The Bad

• Your application needs to be constantly listening for scroll events, which can cause performance issues if it’s not done correctly. Scroll events fire very often, so an inefficient routine can be very CPU intensive. The proper way to deal with this is to use throttling or “debouncing” which gives greater control over execution cycles.
• Following a link on an infinite scrolling page, and then trying to return to the same point on the originating page is very often a frustrating experience, since the scroll position isn’t generally recorded as a ‘state’. This means using the browser’s back button will generally reset the scroll position to the top of the page.
• If you’re using infinite scrolling on a very long page, you’re constantly loading more and more content into memory. Depending on how your page is built, this can have a very negative impact on page performance, since the browser has so much more work to do in order to render the page.
• People understand the concept of a footer, and know that the footer is a place they could expect to find links to important site information. However infinite scrolling means the footer keeps getting pushed just out of reach by the freshly loaded content. It’s like the donkey trying to get to the carrot on a stick – the carrot is always frustratingly just out of reach. Of course, you could use a sticky footer, but that gobbles up screen space for no good reason.
• Currently there is no established way to cancel or opt-out of the behavior.
• Users can’t easily bookmark or use the back-button to return to a specific segment of the page. (this is the detriment that Facebook seems to have capitalized on)
• Analytics will be much more difficult to implement. Just dropping some Google Analytics code into the page isn’t going to give you much insight, so a custom solution would have to be implemented.

Example: Photopin.com

http://photopin.com/search/treasure-chest

Let’s take a look at an infinite scroll that is arguably less successful.

Photopin is a creative commons search engine that enables users to search Flickr for an image or set of images. Since infinite scroll effectively breaks the back button, and this site provides no obvious way to “mark” an image, lengthy searches/scrolls can be very frustrating.

The only way to return to an image you found earlier is to repeat the search and start scrolling.

The usability issues could be handled in a similar method to Facebook’s approach but unfortunately, if you examine the site, you’ll see that the thumbnail modal offers two options when hovered, and neither of them are “bookmark-able”.

Perhaps the theory behind this is similar to Facebook, but in this case force user to download the images that catch their eye whether they need them or just want to compare it to a group of others locally, since there’s no “compare” feature in the User Interface.

The Maybe

So, should you use the infinite scroll design pattern on your project?

Hopefully the content in this article leads you to the strong possibility of a definite maybe. Analyze your needs for the site, the probable user archetype, the predicted uses, and so on.

If implemented well, you’ll enhance the user experience and potentially even boost user interaction, as we saw with the Facebook example.

Poorly implemented – or even simply applied to the wrong situation – you’ll frustrate your users and most likely drive them away.