Infinite Scrolling: When to Use It, When to Avoid It
nngroup.com
nngroup.com
One of the purposes of a scroll bar is to indicate how long (and/or wide) some piece of content is relative to your window. Another purpose is to indicate your current X/Y position within some piece of content.
Both of those purposes are completely broken with the use of infinite scrolling, because the length (and/or width) of the content keeps changing (increasing) and thus your position in that content also keeps changing.
I shouldn't have to explain how terrible this is from both accessibility and simple practicality standpoints.
For example with two sites you now have two URLs and need to figure out which experience a browser should actually see. If I’m on a desktop and somebody sends me a mobile link, which page should I see?
I also think the scroll bar is an entirely desktop tool, and as infinite scrolling most benefits mobile, this is a moot point. Nobody on mobile uses the scroll bar.
Personally, as a middle-click-and-hold'er, I do not use the scroll bar. I just went through my pages and frankly I'm surprised how the bar looks. I honestly never look at it or use it.
As this article demonstrates the scrolling on mobile as well, I have to point out that your complaints are sadly more of edge cases w.r.t. to the products we're making for the general public.
EDIT: Ah! I see it! I have a curved screen and the 1 px thin "bar" is only on the curved edge of the screen which catches the light and isn't visible. Fair enough.
Seems fine to me? New content is appended, so the length and your position changes. Scroll bar reflects what’s going on. What’s the problem?
An accurate and consistent scroll bar is a valuable navigation tool, please don't break it.
Dragging the scroll bar has its benefits over touch/wheel too: It allows for quicker, longer distance travel with fewer (and in the sense that you just move your arm, also simpler) movements.
Opening modals changes the scrollbar length. Opening accordions do too. The scrollbar doesn't "break" when content is added to a page, it just adjusts accordingly. It seems like this is all good, expected behavior; not an a11y concern.
Particularly for the elderly and disabled, but honestly pretty much anyone not familiar with using computers, elements of the user interface suddenly changing seemingly at random is extremely disruptive and disorienting. In the spirit of accesibility, as an engineer you want to eliminate such behaviour because being disrupted and disoriented like that is really unpleasant.
This appears to be postulation on your part rather than actual knowledge of accessibility needs.
The specter of "visually changing things are bad" may hold some water (WCAG requirements do include things along those lines), but in order to discourage folks from using common web components I'd definitely need to see some actual evidence of this phenomenon w.r.t scrolling.
I mean, this whole thread is rife with people telling stories of being terribly annoyed by the shenanigans that infinite scrolling causes. Including issues both involving the scroll bar as well as other forms of navigation that break down with infinite scrolling.
I'm sure you have also experienced moments of disorientation when something you were using (not necessarily infinite scrolling) suddenly decided to do something all on its own and left you to figure out what just happened.
On the other hand, it seems to me that this is partly the fault of the scrollbar as an idea. How do you show the current position in a document for which, for one reason or another, you cannot instantly compute the visible height? I still remember an Android PDF viewer which would run through every page of a 2000-page document to get the page dimensions before displaying anything. (From what I can see, modern viewers display the first page instantly by accepting being caught in their lie when a PDF has pages of wildly varying size.) Even a gigabyte of Unicode plain text with no line breaks in a proportional font is a serious problem. I don’t think we can special-case network streaming here (although it’s not unimportant either).
Perhaps by not "instantly" displaying the document- that is, displaying it before you are able to display its scrollbar.
Maybe the metaphor of the scrollbar is just a bad one?
[1] https://matterandinteractions.org/
[2] https://www.macmillanlearning.com/college/ca/product/Life-Th...
I feel that this is akin to that. I strongly believe both perspectives are valid for often overlapping contexts.
The relative position inside an infinite stream is always 0, and the height of the scrollbar handle (showing relative size of the viewport relative to the entire document) is also 0.
As the size of a finite-sized document grows, these problems also show.
Problems are: you can't click on the handle since its size is close to 0; you can't click above the the handle to do effectively go one page up, since the handle is at position 0 (or close to it).
Scrollbars are pretty useless for large documents, even more so for infinite streams.
"How do you show the current position in a document for which, for one reason or another, you cannot instantly compute the visible height? "
Heck—maybe it’s not even browsers, but websites. I’m pretty sure a website could change the URL as you scroll, so if the page is reloaded (or bookmarked, etc) you’re brought back to where you left off. I usually dislike it when websites mess with URLs, but this seems like an excellent use case!
Reddit used to struggle with this back in the day. The way they did pagination was to say "show the next page after id postId=xyz123". Since the algorithm kept re-sorting the posts on the front page, the content moved around quite a lot and you'd see the same things re-appearing on page after page, and sometimes post xyz123 was deleted and then everything broke.
It’s one of the reasons that the “I can build XYZ app in a weekend” crowd sounds so silly. I bet Reddit spent dozens of not hundreds of man-months nailing their scrolling behavior. It probably took many iterations of UX, product and engineering to get it right. And even now I bet they have a pile of JIRA tickets buried in their backlog relating to the pagination system.
In my experience there is a non linear relation between the more seemless and “easy” something appears and the amount of work that went into it. Things seem “easy” because the developers poured a pile of fit & finish on the system.
Although Reddit's design decisions are almost certainly to accomodate their much larger scale.
Hacker News being designed to display trees sorted by karma also makes it difficult, you would have to re-sort the entire page to re-rank every new subtree within the current display.
Apparently, this also makes pagination difficult, since pagination is implicitly chronological - what people want from pagination is to easily find the latest items - which karma sort doesn't allow.
The latter point is relevant to a variety of UX decisions across many products and services. Making it easy, efficient, and pleasant for the user to do what the user wants may not be the overriding concern in the design.
Which is all fun and games until the “page” is actually a mutable and constantly changing list. With a mutable list there is no concept of “where you left off”.
More specifically it's caused by offset pagination. The kind of pagination where you track "user is 90 items deep into the list" or "user is 3 pages into list and each page is 30 items"
Alternatively, index based pagination works by going "the last item the user viewed was id=12345". With this model refreshing the view won't cause a change, but the downside is you lose an easy way to tell the user how many "pages" deep they are. Even though "pages" is a flawed metaphor in a dynamic stream of data, users still like to see "you're on page 3 of 1 million"
Also this is only considering "append-only" style lists. Like comments sorted by time, or a list of versions of software, etc. If your list is dynamic, like the pages of Hacker News, where isn't ordered consistently but is instead a dynamic order or has mutable items, pagination will still be inconsistent.
The web was designed from the ground up to display documents, so we would have to resort to URL hacks.
HTML can stick around indefinitely for legacy websites and truly static pages, but browsers should introduce a new standard DOCTYPE optimized for what we actually want the web to do.
There’s nothing magical about this that a “real app framework” gives you.
This user certainly does, and, unless there is strong evidence otherwise, I’d go out on a limb and assume that most users would dislike having to “re-scroll” to the point they were in the list.
Pagination doesn't work either, because data can shift and you get repeated elements (if the page size is less than the remaining data when moving back to the start) or else truncated pages, or you start on page 10 and move backwards to page -3 before reaching the start. If you jump to a particular element, it requires you to know the absolute offset of all data to calculate page numbers correctly, which when jumping and filtering a large table might be a significant performance cost. Plus it breaks up content - if you're looking at chat history for example, often related messages are broken up into several smaller messages. Having one message on page 10 and the remainder on page 11 would be a terrible experience.
Don't blame this on designers, infinite scroll has been around (apparently?) almost 20 years now. Browsers still don't have an accessible solution despite the ubiquity of this pattern today - browser devs are to blame.
It's not perfect but I don't really care to improve it and no one has had any complaints.
Check it out here: https://sayartii.com/search
N.b. it's incredibly slow, because it has to load every batch above the scroll position first. Try going to the bottom of the page and seeing how long it takes for results to render.
If you know how many items there are and all the items have the same height, then you can simply set the height of your container for the scrollbar to be accurate.
Furthermore you can listen to the scroll event and load the correct items if the user uses the scrollbar to jump to a particular spot.
So I think the bigger problem is a) people being lazy and not implementing this properly b) using this pattern where the preconditions don’t hold.
It also breaks the back button, in all implementations I have seen so far.
I dunno. Shit ain’t easy once you think about it for a while.
If all you have is a static unchanging set of items… might as well just use old school pagination! At least in my opinion. It’s when the list of items is constantly changing that things get interesting.
The item you wanted to search might get unloaded, or not loaded yet, in some bizarre attempt at optimization when the javascript library resposible is an order of magnitude larger than the actual content anyway.
My phone has gigabytes of memory. If you want to present five hundred items in a web shop, just list them and do not bother with any type of pagination, invisible or otherwise.
I don’t think there is an easy answer here. All options have some trade offs.
I always thought the infinite scroll pattern was designed for analytics purposes. So that you can track user engagement. Not because technology constraints necessitated it or that it was a good user experience.
If you click on an item after significant scrolling, view the item, then click back, where are you? almost never where you were. Usually just at the top of the list.
The scroll bar and find function can be mitigated, but not as elegantly.
The real problem is that, when you load a page in the middle, it’s easy to scroll down, but scrolling UP is glitchy. That one can’t be fixed. https://meta.discourse.org/t/scroll-jank-when-scrolling-up/1...
I love infinite scrolling for random content. There is no “position” so to speak. And there is no concept of “find” since you don’t know what you’re looking for. “Back” continues to work as long as your browser cached the previous page state.
Sometimes you really do want to simulate an infinite list of 4,000,000 entries!
An example: https://wikiscroll.blankenship.io
Scroll position as measured by a scroll bar doesn’t make sense for an infinite (or indefinite) document. That doesn’t make an infinite document bad.
"Infinite" scroll isn't breaking anything, the content all broke scrolling inherently.
And how would you do that when there is infinite scroll?
I think this paragraph lets slip the main reason for infinite scrolling: it encourages users to consume more content, and the "load more" button offers an escape hatch that helps users break out of whatever dopamine-loop they are trapped in.
The examples in the article are all relatively benign shopping examples, but infinite scroll is put to far more insidious use on "content" apps.
Pagination fundamentally puts the user in control of where they are within a document, and how they want to move through it. I'm not convinced at all by the Google example of infinite scroll with integrated pagination, because I strongly expect that there is no stability to the inclusion or ordering of the items; if you revisit the same page the next day, there's little guarantee that "page 2" will have the same items, making "page 2" meaningless, and the experience just as disorienting.
… and honestly what does “page 2” even mean on a site like this? It’s almost a completely arbitrary distinction because the amount of items on each page is just a magic number. And your “page 2” is nothing more than snapshot in time… sharing a URL for “page 2” to somebody else is pointless because they won’t see the same content you did. Bookmarking “page 2” is pointless since it will change almost every load. Having a search engine index “page two” is pointless because “page two” won’t even say the same stuff by the time it gets exposed in the search page (you see this sometimes with SEO results that link to a “stories” page). In fact you might as well forbid search engines from indexing anything after “page 1”
And once you start thinking about it you might just say “fuck it… everything is the same ‘page’”. Instead of a “page” you have a viewport into a infinite, constantly changing pane of content. But since it is impractical to load an infinite list of items at once, you’ve got to load chunks of it on demand. And suddenly you’ve invented infinite scroll.
Recent HN post: https://news.ycombinator.com/item?id=32495846
Again, details matter here, but it is easily solvable.
That's the usual default, but there are usually sort options along with pagination that can make an items place in a list more or less fixed.
Paginated pages are about as linkable as properly implemented infinite scrolling.
Or wants to send a link right now to be opened right now ("Hey honey, which one of these things should I get?").
Links are inherently ephemeral: content changes and expires, and there's nothing that guarantees against that. Doesn't make them useless.
Maybe if you're linking to the page with the dragonfruit on it and a bunch of items get added between that and the banana it might be off by a page, but it'll be close enough to be useful.
Like:
exampe.com/products#offset-999
It has no pagination interface for regular people!
AND YET! It has pagination on the backend! It's a URL parameter!
So I emailed them. At first, they didn't understand, they said the design team wanted infinite scroll, so I said, that's fine, infinite scroll is fine, that doesn't preclude pagination, in fact pagination is already implemented on the backend.
I offered them a couple of possible 5-minutes-to-implement unobtrusive designs and also offered to do it for free. All it requires is links since the backend is done...
https://i.imgur.com/R12ckYU.jpg (the proposal)
They don't care. They choose to die on this hill for absolutely no discernable reason; regular users who can't edit url parameters be damned.
I love them and their mission so much, but good lord, this one particular decision is so stupid. Just put the damn pagination buttons on the site so regular people can use them, they don't know how to use URL parameters!
edit: If the value of pagination isn't self-evident, one of the values of pagination is that it allows you to go back to where you were a different day or on another machine, instead of scrolling through 70+ pages of stuff you've already seen... Or, perhaps, to skip 50 pages to find much older/newer/more interesting stuff, etc...
I have yet to use a service where I prefer having infinite scroll. I always prefer having pages.
I have sometimes used services where I prefer having infinite scroll. I sometimes prefer it.
As others have said it breaks findability, default browser nav (back then forward again you have to start over or watch it gracelessly attempt to autoscroll back down 600 posts and often fail), renders the scrollbar visually near-meaningless, detrimental to performance, and seems to largely be utilized just to maximize scroll time on visibility driven ad platforms, like all popular social media.
What do you like so much about it? Just the miniscule added convenience (that happens to be weaponized against you anyway as stated above)?
Pagination can be "weaponized" too -- note the awful publishers such as WebMD who break articles up into a billion pages, to increase pageviews and hence ad impressions.
Incidentally I prefer pagination for taxonomy pages and search-results pages, because it puts navigation more in my hands.
Good point, hadn't considered that.
I like infinite scrolling.
There is zero reason for inf. scrolling unless we re talking about addictive substances like fb, tiktok etc. Instead , put plenty of entries in each page (it's 2022, we have good bandwidth, people) and use the tried-and-true, browser-compatible pagination. So that i can send a link to a friend, and i won't need to call her to explain how many times she has to scroll down
But it can work, it's just that nobody has bothered to tinker with the concept very much. It's either/or when it comes to infinite scrolling and click pagination.
The big issues for me are:
- it's never really infinite, it's some finite list that will end at a surprising time. There's rarely any context for how much is ahead of you and behind you. Some sites now will give you little contextual hints (ASOS.com for an example) but often it's opaque.
- leaving all of your previous items on the page. So I'm near the bottom of the list but I have a 4000vh list ahead
Sites that paginate without engagement outside of scroll make the most sense to me, where you get a window of several pages and indication of where you are.
[1 2 3] scroll down, [2 3 4]
If I click a link which takes me a new page and then click back I need the page to go back to the state it was, not jump back to the top. Not sure which sites I've had that issue on recently
I also need it not to crash. I haven't tried it in a while but Patreon used to have the issue that I'd sponsor some content creator and then try to go through their 200 posts. Pateron's infinite scroll is manual with a "load more" button that adds to the page. Let's say each click adds 20 posts. So I'd see 200-181, then plus 20 so 200-161, then plus 20 so 200-141, and say 101 the page would F up. The only thing to do was start over at 200 and click more 6 more times. IIRC it's basically if you expanded a few posts it would F up so starting over from 200 and not expanding posts would get you past the point you made it last time.
for a shopping site, infinite scrolling on average improved item views and checkout - average over all product categories, but not all. no honeymoon effect was observed
It's also annoying to fill the scroll with unrelated content -- Twitter (as best as I can tell) seems to do this but I'm not sure how far it goes as Twitter spams login prompts after what I assume is the end of the main thread.
Infinite scrolling IMO is part of the dark patterns that are attempting to collect all of your attention.
Having the mental break of waiting for a new page load is a significant change for me--I'm way more likely to quickly step away from paginated scrolling than infinite.
Good thing mobile is a passing fad and a11y doesn't matter. /s
Their points are wrong and border on naivety.
Page load issues can and should be nonexistent fire to loading via xmlhttprequest/fetch ahead of time, and SEO issues are minor and typically negated by sitemap XML.
There are plenty of other best-practices to address lingering concerns.
Never, Always.
In other words, infinite scrolling promotes addictive behavior.
> especially disruptive for the user experience when websites do not save the user’s spot in the list during pogo sticking. Frequently, users will click on an item in the infinite list or feed to go to its detail page and, when they come back, using the Back button, they will find themselves at the top of the list
^ cmon this is just the design spec for the twitter web UX
If I had my way though... never!
This is such a common problem with web sites that I have reverted to habitually clicking “Open in new tab” when clicking a detail link on these types of screens to avoid this issue.
How this type of terrible UI is allowed and even commonplace on websites (and some hybrid mobile apps) speaks volumes about the company’s regard for its users.
When to avoid it: Always
One, as mentioned in the article, the memory pressure and exhaustion issues - these were the biggest problems when I first started on the project. These were especially a problem on mobile, and a problem as guides grew in page count, page length, number and size of images, etc. To resolve this, after loading a new page, we basically do a rough count of the number of words in all guide pages currently loaded, and if it's over a certain number (I can't recall what it is off hand; 10,000, maybe), we start deleting pages in the opposite direction that the user is scrolling until we're under again - so if they're scrolling down, we remove the "previous"/"up" pages, and vice versa. (Gotta make sure to not actually delete any of the pages that are currently visible in the viewport, though…)
Oh, I guess I should mention that too; we actually have it working in two directions, so when you land on a page from a search engine result, the requested page loads, then we also load in a previous page and a next page. If you start scrolling up and getting near the beginning of the previous guide page, we again load another page above it which you can keep scrolling into if you'd like. That "two-way" infinite scroll is probably a bit more difficult to implement than just doing it in one direction.
Anyway, a huge problem that happens when you're adding and deleting pages like this is that the viewport would jump around, making it really annoying to try to read things. This is especially a problem when scrolling up and getting that page added above the existing content, or when scrolling down and a page above the existing viewport content is deleted. I can't remember the fine points of how I solved this but it basically involved measuring the height of pages as they get added/removed and then offsetting the location of the viewport by that height immediately after adding/removing the page such that it appears to the user that the jump never happened. This also means we had to make sure images on all pages have width and height attributes so that they don't cause repaints which reposition things as they load. Same with ad slots. This sort of math and trying to figure out what the browser is doing got hairy quickly and I always bristle when they want me to go back and touch up something to do with this code, but fortunately it's now in a state where that rarely happens.
Off the top of my head, I recall that another trick we're doing is that if the user clicks the link to another guide page, we capture that click and see if that page is already loaded, and, if so, scroll the user to that guide page rather than reloading the whole thing.
In the end, as a developer, this part of the code is not at all fun to work with, and as a user, I don't particularly like normal browser behaviors being hijacked for the purposes of locking in my attention like that. But I'm a step or two away from having to worry about user engagement analytics and all that nonsense, so I accept that the bosses have different priorities than I do and I do what they tell me to do in the best way I can do it. That's what they pay me for after all.
Edit: Also, we use the browser history API to change the URL appearing in the location bar when the user sufficiently scrolls on to a certain guide page, so for the most part, bookmarking, back and forward buttons, the "History" menu, etc all work as expected.
Specifically, infinite scrolling, where the remaining/invisible data is not loaded until getting towards the end of the loaded segment.
For the visually impaired infinite scrolling breaks search and text-to-speach tools.
A better solution is give the option to paginate with the set size, 25, 50, 1000, or whatever; or load the entire list in one shot.
* infinite scrolling turns webpages into web apps yet not everyone likes or expects web apps;
* infinite scrolling fails to tell people when they reached the end and this is frustrating;
* infinite scrolling fails to tell people how far along they have consumed the content, or how far back is the top bar;
* infinite scrolling breaks the basics of UI tools (no scrollbar, no end key, no home key)
* infinite scrolling should never be other than a gesture for more (scroll for more)
* infinite scrolling should still allow for going "back" e.g. either it scrolls back up and/or allows for going back to the beginning.
* infinite scrolling should have an "end" e.g. a bar at the bottom that phases away when scrolling further down and then appears at the next end.
* infinite scrolling is a bad habit for more, and may be should be discouraged e.g. electrocute the user every time he asks for more /s
I hope you agree.