TL;DR: While infinite scroll does provide a solution in some cases, it can be less than ideal for users.

👁 Image

Infinite scroll can be disorienting, uncontrollable, and can cause your users stress.

In this article, we will explain why you need to stop building websites with infinite scroll. But to start, let’s look at a brief history of scrolling.

A brief history of scrolling

To understand what scroll really is, let’s see where the term scroll comes from.

scroll (n.): c. 1400, “roll of parchment or paper”

Scrolls originally were used for when information became lengthy (like religious contents). So much content became difficult to manage, read and write.

When computers came into our lives we still needed a way to navigate through large pieces of content.

The evolution of scrolls in computers

1. Lines (and columns)

In the early years of the internet, UX designers invented/explored many ways of paging/scrolling the content. Before the web was popular, we were scrolling lines on our screen.

Horizontal scrolls made scrolling a tool not only for reading the content, but also a way to navigate on the computer screen.

2. Windows (not the OS one)

Using scrolls to navigate the screen encouraged people to create windows. Using windows, you would be able to view multiple pieces of content at one time.

👁 Image

3. Webpages

Scrolling solves a very fundamental problem we have while browsing webpages. However, scrolling can cause many issues for users and can negatively impact the user experience. Let’s take a closer look.

The experiences invented to navigate webpages

I’m going to try to define how developers and designers created experiences to navigate users in their webpages.

Let’s start by learning some back-end pagination systems:

Offset-based pagination

This is the most known pagination system. In this technique, first, we have to find how many items we have to paginate:

-- All posts count
SELECT COUNT(*) AS total FROM posts

After counting all the items, we have to calculate the pages. Let’s assume we’ll show 10 items per page:

-- First page items
SELECT * FROM posts LIMIT 10

And if we want to skip to the page 3, we need to skip first 30 items using OFFSET:

-- Third page items
SELECT * FROM posts LIMIT 10 OFFSET 30

And we will send the pagination information to the client as follows:

{
 "pagination": {
 "items_count": 100,
 "current": 3,
 "total_pages": 10
 },
 "items": [...]
}

Pros and cons of offset-based pagination

• 👍 Good: Easy to jump to any page
• 👍 Good: The client experience is more free
• 👎 Bad: Performance issues
• 👎 Bad: Duplicate items may be shown if data changes

Cursor-based pagination

Big data made it hard to calculate the table count since it is constantly growing (think about Twitter). So, developers came up with newer techniques to paginate the data: cursors.

Every row must have a unique cursor. You do not have to count the whole table which makes it impossible to know actual page count:

-- Get extra 1 item to get its cursor.
SELECT * FROM posts ORDER BY id DESC LIMIT 11

Assume every post has a unique cursor field (or its ID in this example) to help pagination. The client will have pagination information as follows:

{
 "pagination": {
 "next": 1234 // extra item's ID (cursor), null if end of data.
 },
 "items": [...]
}

And you can ask for the next page using cursor:

-- Offsetting records using 1234 cursor
SELECT * FROM posts WHERE id >= 1234 ORDER BY id LIMIT 11

Pros and cons of cursor-based pagination

• 👍 Good: More performant, no table counts
• 👍 Good: Showing duplicate items is not possible if someone inserts a row in the center of the table
• 👎 Bad: Impossible to jump to any page
• 👎 Bad: Client is not free with the experience, total page and current page are not calculated

Let’s take a look at some navigation techniques.

Next and previous

The experience: click-based

The technique: offset-based or cursor-based

This is mainly used to navigate blogs. This is the oldest version of infinite scrolling. Using this approach, the user may not know where the content ends.

👁 Image

Numbered pagination

The experience: click-based

The technique: offset-based

This is the most usable (according to me) navigation type. It uses offset based pagination which allows you to jump to the page you want, or go to the end or beginning with just one click.

👁 Image

Google uses this kind of navigation in search results:

👁 Image

Load more

The experience: click trigger-based

The technique: cursor-based  — may also be offset-based but would be awkward

This is one of the newest pagination techniques, and it also uses the previous version of infinite scrolls.

👁 Image

In the example above, the user clicks the “Load More” button to see more content.

Infinite scrolls

The experience: scroll-based

The technique: cursor-based  — may also be offset-based but would be VERY awkward

Infinite scrolls are the newest experience of cursor based pagination techniques.

Hugh E. Williams claims he invented infinite scroll in 2005 on Microsoft.

Metafizzy also created a tool to help developers build infinite scrolls.

👁 Image

Stop building websites with infinite scroll!

Up until this section, we have reviewed how we got here. Now let’s talk about why here sucks.

Finding footer

Footer is a very basic unit of webpage anatomy, just like a header. Sites keep some detailed information and links in the footer such as phone numbers, addresses, and help and support links. If users are searching for this detailed information, they mostly scroll down to find the footer.

With infinite scrolls, users can have a hard time trying to find the footer. Infinite scroll makes finding the end of the page impossible. Not being able to reach the bottom of a website can make the user stressed (which is not great).

The sites with an infinite feed (like Twitter) solve the footer problem putting this required information and links in the sidebar. The sidebar is a solution to this issue, but not a good one. Footer should stay on footer.

👁 Image

Do not use infinite scroll if you do not have a timeline or feed

Social media applications work with time. The users’ intention is to navigate the past. In this case, infinite scroll makes the navigation easier. Here, infinite scroll is good for performance, especially in mobile.

But if you have an e-commerce, news, magazine, or a blog website, and the user’s intention is to move around the items or articles, infinite scroll becomes a nightmare for them. In a timeline-based list, people mostly don’t look for a date or unique moment. On item-based lists, the user wants to find an item. Infinite scrolls make your items almost impossible for your users to find.

Give users more control

Users generally do not like the UIs when they feel they cannot control it.

A scroll event is not very intentional to do something. People navigate the page, and if they want to call an action they mostly click or touch (known as triggers). They inform the UI about their decision. But scroll is triggered without any decision.

Infinite scrolls make the pages less controllable for the users. Users can also encounter jumping glitches.

Instead of infinite scrolling, put a “load more” button, which is a trigger. This will give control to the user. (I’d prefer old style numbered pagination but we assume we use cursor based pagination right now).

Allow users to go wherever they want

People navigate between pages, bookmark some of them, share pages with their friends, etc.

However, infinite scrolls cannot keep the state by its design. Users cannot share their current state — which also means you cannot track users’ actions using analytics tools.

If your back-end pagination technique is cursor-based, it’s almost impossible to allow your users to go wherever. If you have an e-commerce website, give users control to navigate to the products they want.

Additionally, if you have a “sort by” functionality in your listing, you must show the user a pagination. In an alphabetically ordered list, you mustn’t force users to scroll down to products starting with K. They will go mad with this experience.

You should allow users to see where they are. Users scroll for a time, and because it’s a stateless design, they do not know how many times the “next page” loaded. When they refresh the page, they will reset all the way back to the original page. The user will then have to scroll back down to find where they were before.

Conclusion

Infinite scrolls are nice in a few cases, but they are usually not problem solvers, but problem makers. UX people shouldn’t consider infinite scrolling as a silver bullet to solve their pagination issues. Stop building websites with infinite scroll.

---

👁 Image