TL;DR: While infinite scroll does provide a solution in some cases, it can be less than ideal for users.
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.
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.
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.
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.
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.
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:
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
-- Third page items
SELECT * FROM posts LIMIT 10 OFFSET 30
And we will send the pagination information to the client as follows:
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:
"next": 1234 // extra item's ID (cursor), null if end of data.
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
Let’s take a look at some navigation techniques.
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.
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.
Google uses this kind of navigation in search results:
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.
In the example above, the user clicks the “Load More” button to see more content.
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.
Up until this section, we have reviewed how we got here. Now let’s talk about why here sucks.
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.
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.
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).
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.
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.
Install LogRocket via npm or script tag.
LogRocket.init() must be called client-side, not
CRDTs, or conflict-free replicated data types, is a concept that underlies applications facing the issue of data replication across a […]
We explore the fusion of TensorFlow and Rust, delving into how we can integrate these two technologies to build and train a neural network.
SignalDB enables automatic data synchronization between your components and a local in-memory or persistent database.