Design & UX
Article

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

By Christian Leeds

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

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:

Netcraft results for Infinite-scroll.com

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: http://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

Facebook implemented infinite scroll long ago

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.
  • Carrots on a stickPeople 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

Photopin.com -- a creative commons image browser

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.

Christian Leeds
Meet the author
Christian is highly experienced in web design and development, web business and marketing. He provides consultancy services through MediaCarbon focusing on media strategy.
  • http://www.blue-dreamer.co.uk/ Rob (bluedreamer)

    While I agree that infinite scrolling does have some use cases, in my experience it only leads to frustration where there is seemingly an unlimited number of items to fetch.

    Whilst watching people use this sort of content presentation they usually give up after a certain amount of scrolling, after getting fed up with it or not finding what they want.

    Then there’s the question of when you click through to a single entry page, when you use the browsers back button you have to re-scroll through everything to get back to where you were.

    Finally there’s also browser/system limits. Pulling in a lot of content into a single browser tab can crash the app, sucking up the users RAM, image sites are particularly bad. Not everyone has an all powerful machine to use.

    • Anthony Pero

      Let me second your last issue. My wife notoriously keeps many tabs open, and frequently, I find she has two or three, sometimes FOUR FB tabs open in order not to lose her spot. E.g-She will right or alt-click and open a new window in FB to read something so she doesn’t experience the problem of losing her place in the newsfeed… the problem is, she forgets that she did this, and then clickcs the header image to return to her news feed. You can imagine the amount of RAM that is sucked up by Chrome having four FB news feeds open with about 100-1000 posts loaded each. Yes, its operator error, but its also not that uncommon.

  • http://uk.linkedin.com/in/karlbrownactor Karl Brown

    It’s definitely a case of “pick the right tool for the job”. While it works on sites like Facebook and Twitter, it wouldn’t work for e-commerce, and I think you would need to be very careful with the UX and implementation if doing it on a news site.

    Social media tends to be more transitive; you don’t “bookmark” a shared status on Facebook, but you do bookmark an article on a news site or a product on an e-commerce site. It could be that the nature of the content or the purpose of the site is the ultimate arbiter as to whether or not a site should use infinite scrolling or not.

    If it’s going to be used, it has to be implemented correctly so we don’t make it harder for people to use a page. It’s very much “progressive enhancement” in my mind; Facebook wouldn’t break if they removed infinite scroll, so it shouldn’t be the default go-to just “because it’s cool”.

    • Pete

      I’d second your comments, although in my view, infinite scroll really only works best for long article type documents. Newspapers sometimes use them to great effect for in-depth articles combining graphics, videos and side-boxes. The acid-test question is “will your user want to read the entire page?”. If the answer is no, infinite-scroll may be a bad choice. Poorly used by ‘me-too’ developers, infinite-scroll pages are an abomination: a prime examle of using the wrong tool for the job, and the fact they suck up resources just adds to the frustration with amateurish web development

  • Murray Chapman

    Having started in web design during the late 90’s, I learned that most people would not scroll past two screen heights. People clicked more to go to their requested data pages and to much information on a single page was simply to much. When MySpace came along, over the space of two years, the game changed and people started scrolling more. Pages got longer and people scrolled. I guess that as the changing of the times. It is kind of like comparing rules of design that stick (eg. don’t make the user click more than three times to get to their data), and influences that have a short life but have a big impact at the time. (Eg. flat design). You see it coming and straight away can tell if it is a stayer or a short lived experience.

    The breakdown of Good, Bad and the Maybe sums it up really well. Yes, the scrolling is nice when you want the user to stay and read more. The bad being that the processor load can be increased and not being able to return to where you left the long page. That could be another article discussing how pages store virtualised vs caching vs a myriad of other imposed issues on memory management, browsers etc.

    The maybe… To me, infinite scroll (like most other elements of design and UX) is about balance, honesty, reflection, learning and growth. Did it work, what can I learn from my experience etc… What am I presenting and what is more important, a swishy interface or is content still king? Can we do both?

    It’s learning and I can say a massive thank you to the community out there that are passionate about sharing (including the author of this article). This is how we learn collectively and it is a a fantastic way to grow.

    Note: I actually scrolled down to see if the article was paginated :)

  • http://www.giselagiardino.com.ar Gisela Giardino

    Great article, thank you! A horrible implementation of the infinite scroll is the last flickr design (it’s a hybrid, actually because there is some form of strange pagination behind it). When you load the page of a user it keeps retrieving and retrieving photos as you scroll down. Photos which don’t load well because they are just so many the connection can handle at once. The end result is a mosaic of broken images in between loaded images, so you have to reload the whole page again, hoping to see those you missed. But it doesn’t work. And you have no chance whatsoever to bypass this way of displaying the photos. Try it. It’s really anoying. I don’t know why they did so much harm to flickr over the years. It used to have a very simple and clean UX design. Another example of bad implementation if on facebook photo albums. If your album has 300 pictures as you go down you will never reach the bottom of the album to make a comment, like or share UNLESS it loads the whole 300 thumbs inside it. Wrong.

  • http://adrianroselli.com adrianroselli

    Under “The Good” heading above you make seven assertions with nothing to back them up. In fact, in my own user testing, polling, and anecdotal experience, I find your assertions don’t fit.

    The point you make that “accessibility is maintained” is the most egregious of your statements. Every accessibility test I have done with any infinite scroll has shown that is not the case. It’s not just inaccurate, it’s completely wrong. In fact, given the recent uptick in lawsuits for inaccessible web sites, infinite scroll is one of the first items I tell clients must be discarded to limit exposure.

    After I witnessed a particularly ill-advised attempt at making an infinite scroll this past spring, I created a quick checklist (with feedback from other UX and accessibility experts) that a developer should be able to meet before ever diving in, which I hope others may find useful:

    1. Can the user hit “back” and return to the exact same place?
    2. Is there paging for when the JavaScript breaks?
    3. Does the page have a footer?
    4. Can a keyboard user access all other content on the page?
    5. Can you share a URL to a specific place on the page?
    6. Can a user easily jump ahead a few “pages” to quickly get to content much further down the list?
    7. Does the memory footprint of the page dramatically increase after just a couple new “pages?”
    8. Is there a way to disable automatic infinite scrolling and lean on standard paging?
    9. Have you conducted any user tests?
    10. Are you satisfying a use case that has come from research or user request?
    11. Do you have any analytics/tracking to measure success?

    Full context for each point is at my site: http://blog.adrianroselli.com/2014/05/so-you-think-you-built-good-infinite.html

  • M S i N Lund

    A good test, is to grab the scroll-bar and move it half a page or so, up and down a couple of times.
    Are you
    1.) shown the same content each time you return to the same position,
    or is it
    2.) something else every time?

    If 2, then the designer is an incompetent clutz, and the site hates its visitors.

  • Lisa

    I scroll passed the first few results. Then I get stuck wondering when it will end, how many results remain… should I bother continuing (ebay app, for example)? I had to buy a touch tablet because most of the infinite scrolls are not pen friendly, bounce you around when you are holding the scroll bar. I’m not a fan of it on desktop.

  • Tarian

    Infinite scrolling has no place on the internet.

    Scrolling is work – compared to seeing the initial page of content – or Contents (links) – preferably in one view.
    So scrolling should NOT be a design goal.

    Clearly some content demands to stray below the fold – but one or two pages should be the maximum.

    Any more is disorientating – making harder to remember where to find that previous interesting content.

    In short, content should have a definable place.

    That MIGHT be below the fold – but it definitely should NOT be at some indeterminate – and unmemorable place down a massively long infinite scroll page.

    Surely this should be obvious?
    What does the site owner thinks happens to content 10, 20 or 50 pages down?
    It hardly gets read !

    Surely if the site owner wants it found, he/she would signpost it – with a direct link (ideally to a distinct page)?

Recommended

Learn Coding Online
Learn Web Development

Start learning web development and design for free with SitePoint Premium!

Get the lastest in Design, once a week, for free.