4 reasons why you might want to avoid infinite scrolling

4 reasons why you might want to avoid infinite scrolling

Infinite scrolling is a somewhat popular UI/UX technique for loading content asynchronously to the user. In a sense, as you scroll through the page and near the bottom of your content, you make another request for more data and attempt to load another chunk of content smoothly onto the page.

This ensures that the user can continue to keep scrolling uninterrupted, infinitely. Or until you run out of content to render. Theoretically, this should increase time-on-site and perhaps introduce content to your users that they would otherwise have missed.

However, it isn't an ideal interface for every situation. It does have a few downsides associated with it which aren't technical in nature, but more related to usability.

4. Removes the footer

The footer, though the last thing that most users will see, is a vital part of any website. It usually behaves almost like a sitemap where users can easily, in one swoop, see all of the important links on the entire website.

If you have a well-built out footer section, an infinite scroll layout essentially makes it impossible to get to. The more you scroll, the more it gets pushed down into the unknown regions of the page.

A kind-of fix is to set the footer's position to fixed and to stick it to the bottom of the page always, so that it remains in view at all times. While this works, sometimes footers tend to be on the larger side, and really the last thing that your site visitors want to see is 50% of the screen being taken up by links.

Another potential workaround that a couple of the bigger sites implement is to move the footer from its traditional location (bottom of the page) to a left or right side bar. Still a valid approach, although not intuitive as most users won't necessarily know to check there for footer links.

I personally would favor a useful footer over an infinite scroll mechanism mainly for the increased usefulness to site visitors.

3. Impossible to skip pages

Infinite scrolling does have pages, in a sense But they load sequentially one-by-one, kind of like a linked list. If you want to navigate to whatever content is on page 30, well, then you will have to click on the 'load more' button 29 times.

The truth is we are very visual creatures. We remember images and banners and logos and such. So when we are looking for that one specific item that's on page 5, by page 3 we know that we are close. We remember passing by a certain post on our way there, so we can click on the page 5 link and just jump around.

Infinite scrolling removes that freedom from the user. A good UI/UX design doesn't necessarily mean that we have to trick users into staying longer by mindlessly scrolling. It means giving the users the tools to find what they need so that they can get n their merry way.

And yes, I do not have numeric paging on my articles listing. I use the "load more" pattern to render content to page. However, I do have a fallback mechanism that loads true pages so that you can navigate in the traditional /page/2, /page/3 way.

Pagination is difficult.

2. Accessibility issues

While there is a role in the ARIA specification for infinite scrolling, things get complex here. There is alot more to being accessible than simply a screen-reader or voice command. For example:

- Can a user go back a page?
- What if JavaScript is disabled
- Can a user share a page with someone?

Here is a really good article that I stumble on with first-hand experience of someone who relies on a screen reader and they made some very valid observations. The main issues were some of the ones that I have already mentioned, such as a screen reader not being able to locate the footer or in some cases continuously loading content until some unknown endpoint.

Again, a good UI/UX helps any user to find what they are looking for quickly and effectively so that they can be on their way.

Having said that, it is possible to create an accessible and infinitely loading experience, but not without accounting for the aforementioned situations. You would still need numeric pagination so that users can navigate to the desired content. And in case of disabled JavaScript, you would still want users to be able to link to page/2 or page/20 to find what they need.

It's definitely a more involved commitment if you want to have this type of navigation in place and to do it well.

1. Addictive mechanism

More recently, social media companies were on the spotlight and criticized for creating addictive mechanisms that would keep users on their websites longer getting served more and more ads. While not specific in which mechanisms, you can guess by your own usage habits (mine too) that infinite scrolling is a very addictive interface. At least, it can be.

It creates that slot machine effect each time that you scroll downwards and you see the loading icon (sometimes no icon). Even the loading icon is a part of the mechanism. It creates this artificial tension as you wait those 1-2 seconds. Though truthfully, most websites pre-load data ahead of time, so the actual time to render is almost instant.

Personally speaking, I am not fan of gamified addictive design. It makes it hard to gauge whether I am actually producing high-quality content or whether my thumbnail images are catching your attention more than anything else.

It really is more challenging to come up with a genuinely helpful and high-quality content that gets shared online or that grows organically in search engines than it is to confuse your dopamine receptors.

The middle ground that I choose, is the "load more" button, with optional page numbers. This way, the user is in charge of the experience and can control when they have seen enough content. And the fallback pagination controls really just make your websites more usable to more people. People that for some reason just can't scroll infinitely, either due to technical issues or permissions issues.

I'm not ruling out infinite scrolling as a potentially more useful mechanism just yet, but it does need work before it gets there.

Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.

Community Comments

No comments posted yet

Developer Poll Time

Help us and the community figure out what the latest trends in coding are.

Total Votes: