Infinite scrolling is universally bad for one, very simple reason: It breaks the scroll bar.
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.
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.
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.
Jira goes one better. Issues in some lists are paginated into 50s. Change to "page 2", use the back button and you'll be back on the page you were on before looking at the list, because the URL hasn't changed. Go forward again and you're back at the first page. Argh!
Gah! Breaking basic navigation functionality, along with the clipboard, on page search functionality (i.e., basic application and OS level stuff), keyboard navigation, and common keyboard shortcuts and mouse/touch gestures, are amongst the absolute cardinal sins of web applications. These ought to be acceptance criteria for every single "story" implemented that impacts the client-side. Does anybody do it? Well, some, but very few.
The back button problem is fixable. Discourse (which you’ll see on discuss.python.org and users.rust-lang.org) uses the history API to keep track of your location. You can create a URL that points at any individual post, and the page will appear “pre-scrolled” to it, so you can not only use the back button to return to your location in the infinite scroll, you can even bookmark your location in the infinite scroll.
The scroll bar and find function can be mitigated, but not as elegantly.
Gigabytes of memory yes but there is load time and render time too. And rendering a 120mb payload of items and their thumbnails before I can even view the top of the page seems… not the best user experience.
I don’t think there is an easy answer here. All options have some trade offs.
Typically when I serialize data for #index endpoints I return much slimmer payloads than I do in #show endpoints. I recognize that 120mb was an extreme, but you should be able to serialize lists of 500+ items into well under 1mb, with enough data to render your list view thumbnails/links.
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.
Deferring rendering of the images seems like an easy enough thing to do if your alternative is infinite scrolling. Pre-load the text and layout but leave the images and video until they're close to the viewport.
That is not how browsers work. The browser will render the viewport immediately, long before the page has loaded. It will also load the visible thumbnails first, unless made impossible by complicated markup of course. Otherwise surfing the web on dialup in 1996 would have been intolerable.
Sooner or later you have to unload content or the browser crashes. There's an upper limit to how many DOM elements browsers can handle, even with modern optimizations.
the lack of not being able to find something not yet loaded or recently unloaded is infuriating to me. I file shitty pagination systems with no Show All in the same category.
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!
I find spotify is really bad with unloading ui, to the point where you have to stop and wait to see song titles if you are scrolling even moderately fast
In fairness, without unloading, it will be slow. Really slow. I never added unloading to a long list in my app, and for lists with thousands of items, Chrome will take seconds to paint on my MBP if you do any vigorous scrolling. It's not about memory use, it's about practical browser performance.
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).
> I don’t think we can special-case network streaming here (although it’s not unimportant either).
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.
I recall desktop UIs solving this by having a minimum scroll button size. Then just aligning the bar to the full height of the doc, at least where the data size was known. And when first loaded the bar would sometimes shift as it loaded, albeit without having to scroll to force further loading.
I remember Android apps some years back that showed an approximate scrollbar, when it knew how many items there were (paragraphs, in the case I’m vaguely recalling—and although all the content was available, it might not have wanted to render it all at once, as it could have tens of thousands of words) but not how tall each was. I think it drew a scrollbar with the assumption that off-screen items would be a certain height, so if you went from a screenful of long paragraphs to a screenful of short paragraphs the scrollbar could be amusingly wonky, considering our usual expectation of spatial scrollbars. In some contexts this itemwise rather than spatial scrollbar can actually be more useful, but whether or no, it’s not a concept the web supports directly, and there will be certain niggles in the result of implementing it.
"How do you show the current position in a document for which, for one reason or another, you cannot instantly compute the visible height? "
Actually, that sounds like an idea, make the height of the page roughly the real height of the total pages. It can still load content on scroll, but being able to leap ahead a few pages sounds great. Now if we can just get it to remember our position when we hit back, and not just return us to the beginning of the adventure, then infinite scroll would be tolerable.
That seems silly as well, doesn’t it? Why should I wait for all the 1030 pages and 155 MB of Matter and Interactions[1] or 1442 pages and 126 MB of Life[2] to load before I can do anything with it? (Not that a hundred meg should take that much time to load, but then you realize PDF is the moral equivalent of a bunch of gzipped JSON files pointing to each other...) It would be handy if PDFs included an index of all page sizes in a single place, but they don’t, so we need to make do with what they do include somehow.
But why on earth would I want to wait for a document to open, just so the height of the scrollbar is accurate when I see it first..? That is such a minor detail when viewing a document.
Maybe the metaphor of the scrollbar is just a bad one?
Could someone remind me what the name is for the eternal debate between the two valid camps: “HTML should never ever render if there’s an error” vs. “Renderer should try its best to render part of a document if there’s errors” ?
I feel that this is akin to that. I strongly believe both perspectives are valid for often overlapping contexts.
Draconian error handling vs Postel’s law? Both behaviours are still in browsers for XHTML (and XML+XSLT) resp. HTML (though the removal of <noscript> in XHTML5 makes me sad).
Scrollbars can be dynamically updated as the content is processed. This is also a distinct advantage of a proportional sized scollbar elevator like those in Windows since the elevator shrinks to its final size rather then starting at a small fixed size and shifting around.
That's like claiming every data collection should have a reasonably limited length. Even if that were true, scrollbars in general break when the data gets too large (a pixel of screen movement jumps pages of data) not to mention browser layout performance, memory requirements, etc.
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.
Infinite scrolling also immediately destroys the concept of a footer. IME (building websites/apps for a living since 1998) footers are an excellent and underutilized place to put large amounts of supporting materials, expanded navigation links and related affordances. Consider the absurdity of infinite scrolling in a page with a layout containing a footer that can never be reached (perhaps briefly glimpsed before being pushed out of sight).
This is my primary issue with infinite scrolling. However, I wonder if it’s mostly a problem with today’s web browsers.
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!
...I guess, to be quite honest, I'm starting to think we've reached the point where we ought to throw everything out and start over.
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.
This doesn’t make sense. You can build this feature into a web app. It just isn’t often worth it when items aren’t in deterministic order, you’d have to track the hundreds of items the user has already scrolled, and the user doesn’t really care if they start over.
There’s nothing magical about this that a “real app framework” gives you.
> the user doesn’t really care if they start over.
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.
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”.
This is caused by pagination. Without pagination, there's no pages that can get out of sync.
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.
even if the website did re-start where you left off (difficult), what if you scroll backwards? When you send a link, should it point to the page that you scrolled to, or to the beginning of the list? How many items before/after should load? These arise solely because people chose to reinvent a browser -in-the-browser. With pagination we dont have these issues, the link points to a specific results page, uniquely.
You can still have weird issues with pagination if the data set you're paging through is mutable.
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.
Infinite scroll or not you’ll have this problem on a mutable set of items. You’ll have to dedupe the next “page” either client side or server side. Or something!
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.
IIRC the first version of reddit and the Python rewrite were each more or less built in a weekend. They were neither scalable to millions of users nor heavily optimized to keep users on the site as long as possible.
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.
Infinite scroll isn't really useful in a low velocity environment like Hacker News, hot threads being the exception.
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.
This is the killer for me. I’ve gone from loving GitHub to hating it for this one quirk. When you reload the page while viewing a PR, you invariably land at some random spot instead of where you were.
What is “back” on a dynamic page like Reddit, Facebook or even this site? If “back” means “show me exactly what I last saw” it might mean you are showing stale data.
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.
e.g. FB create a search for their website, apparently this is because browser's don't work like user's need. sometimes, I find there are 3 different search box on one FB page, I should remember which one is it...
> 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.
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?
Because not everyone has the hand-eye coordination and/or motor skills to keep track of an arbitrarily changing scroll bar, particularly the elderly and the disabled.
An accurate and consistent scroll bar is a valuable navigation tool, please don't break it.
Hm. Do the the elderly and the disabled keep track of the scroll bar length? Does it getting longer actually confuse people? I'm not convinced this is as important of a thing.
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.
Most of us take for granted the fact we are all still physically and mentally fit (and also know how to operate computers!). Inevitably though, age will catch up to us one day.
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.
> 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.
>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.
Clicking/touching the scroll bar and dragging it directly is a valid way of using a scroll bar. Especially for people who come from a time when mice didn't have scroll wheels, clicking and dragging the scroll bar itself predates the convenience of whole-screen dragging (touch) and flicking the scroll wheel.
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.
This doesn't appear to be infinite scrolling. I can scroll to the bottom of the list with Cmd-Down. It just appears you're lazily rendering results.
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.
I have seen infinite scroll paradigms that simply load the next bit of content, causing the page to elongate, causing the bar to shrink and reposition. This is fine to me as the bar remains in exact sync with the document.
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.
I use the scrollbar on mobile. It's a way to quickly navigate to a section of a particularly large document that would take tons of swiping. Not a frequent use case but an absolute necessity on occasion.
I legitimately cannot get Chrome for Android to show a scroll bar under any circumstance. Android 13 / pixel 6 pro / Chrome, there is simply no scroll bar on any page no matter what.
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.
I think this depends on what kind of content you are scrolling.
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.
Some datasets don’t have a natural order so a position is arbitrary. You just want to iterate over all of it in some useful sequence without arbitrary seek.
It is possible to implement infinite scrolling and maintain the scrollbar height if you know the full number of results you’re going to scroll through and the height of each element (both of which are usually knowable). You simply set the scroller div to elementCount * numElements regardless of the number of elements. Most libraries that provide infinite scrolling do this.
Not only this, but every time it happens I have to wonder how it is that designers have never tried to actually use the scrollbar, getting to the bottom only to have it double in length, the placekeeper jumps out from underneath your cursor, the scrollbar then detects your cursor, and bam, you just skipped half the content without meaning to and it is virtually impossible to get back to where you were. This gets even worse when it isn't a list of entries you're reading but a single very long article or comment thread that should have just been paginated to begin with. It seems entirely motivated by a basic laziness of not wanting to create separate mobile and non-mobile views and defaulting everything to mobile-friendly even if it destroys the browsing experience of people using ordinary desktops and laptops.
Not maintaining a separate site for mobile and desktop isn’t lazy. Having two separate interfaces is not at all easy and it has its own set of trade offs.
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?
> One disadvantage of Load More buttons, compared to classic infinite scrolling, is that interaction cost increases - users have to click the Load More button to load more content. Even the small interruption of clicking Load More might make users consume less content and cause them to switch tasks.
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.
I think the difference is whether the content is truly infinite or not. If there's enough content such that you could spend an unhealthy amount of time scrolling, then you are sacrificing your users well being for engagement. If there's a finite amount of items, the "expand the list as you scroll" approach is pretty reasonable. At that point you can't really call it "infinite scroll" anymore
Infinite scrolling makes the contents of the page unlinkable, breaks searchability and caching. It always makes the experience worse for unclear benefits. What's the problem it solves? Not resending the header and the footer on changing pages? Really?
It's not solving a technical problem. It's trying to avoid points where the user has to make an active decision to continue looking at whatever is being served and thus have a chance to decide to leave.
Not necessarily, if the URL has some absolute position like the ID of the first item instead of the relative number of pages between the newest item and the current page. I believe that Reddit does something like that (of course, only if you sort by new).
Not just product catalogs but sites like HN. “Page 2” on this site changes constantly.
… 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.
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.
Pagination doesn't make things any less linkable than "infinite scrolling with <X> content present," it just makes the limitation more apparent because a page seems like it ought to be linkable.
Not only does archive.org have infinite scrolling...
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...
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...
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)?
I would prefer my main feed on Twitter to be infinite scroll.
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.
The latest ikea redesign is , oh boy how awful. I wonder if they are losing sales already?
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
Sure but on a dynamic site, there is absolutely no guarantee that what’s on “page 2” for her is what you saw when you copied the link. It’s dynamic, after all.
There should always be an option to paginate. As others have said, the user-hostility is significant on any infinite scroll — one side-product of this is the refusal of apps/sites such as Twitter (sometimes) or Facebook to stay where the user left off, reloading the page when the app or page is returned to. (One other truly hostile aspect of such sites: the user's choice of display order, especially on Twitter, is rarely respected, returning always to what the site believes to be most advantageous to itself. User settings should never be changed remotely, or without user approval.)
I've never been a big proponent of infinite scrolling even when it was the approach du jour in the early Rails/web 2.0 halcyon days.
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.
I think my only problem with infinite scroll is poor implementations.
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.
My biggest issue with infinite scrolling is that content position is not preserved in the URL. Page reload/history back returns to the top of the page and specific position cannot be linked
I can't think of a single good reason to have infinite scrolling bar but I have been asked to implement them multiple times. Bad, bad, bad... for the user.
for a major job portal we tested infinite scrolling, the main KPI "job posting views by job seeker" went down after a honeymoon period of ~2 weeks - compared to pagination
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
Infinite scrolling isn't so much of an issue but I've noticed a few sites don't seem to handle feeding content into it well even when they undoubtedly have the content to back it. A few image sites I've checked seem to do this pretty poorly and reload previously loaded content repeatedly and it's annoying; I understand what is happening on the server side, but I'm shocked that this happens. Even Youtube does this and the video I just watched is in the suggested videos feed fairy high up on the list, which makes no sense to me.
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.
> "Infinite scrolling is also not a good fit if you have a large user group from areas with low bandwidth or if your website is visited frequently by users with accessibility needs."
Good thing mobile is a passing fad and a11y doesn't matter. /s
Infinite scroll is one of the several cancers of modern web development. It breaks the scroll bar, it ruins search on the page, the back button stops working, it's a pain for people with accessibility issues. Never use it!
My confidence in the guidance from this article was shaken when it talked about “Increased page load” and “Poor SEO performance” issues.
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.
OpenAI Dall-e uses infinite scrolling to display your saved images. If your window is large enough to not have an active vertical scrollbar, it will never load all your images. So, instead of pagination, you have to resize your window to the size of a phone and rage scroll downward to load more images. Odd UX choice.
I remember browsing a website where I wanted to check the about us section footer. Every time I reached the bottom to click on the footer link it triggered the infinite scrolling. Felt like I was playing cat and mouse. Horrible.
Maybe when presented with such an unfortunate design you may be able to search the items for a nonsensical search term, resulting 0 items in the list. Then, the footer should be visible.
> lack of landmarks to help users orient themselves. With pagination, users may remember the page that an item was on and that an item was close to the top of the page or towards the middle, but in an infinite list of items, it is hard to remember the location of any specific item and return to it.
> 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
“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, having to scroll down through screenfuls and screenfuls of already seen content.”
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.
I picked up a client site which uses infinite scroll, so though I didn't do the original implementation, I've done a lot of work and improvements on it. It's basically a site which publishes video game strategy guides, so it gets a good amount of search engine traffic from people searching things like "how to beat X boss" or "how to find Y item in Z level," and the site owner is very interested in making sure the people who hit those pages can smoothly find the other pages (and the ads thereupon) in a guide. Here's some thoughts on the problems and challenges we've faced.
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.
There's also the bit where you put important contact, privacy, or similar information below the infinite scrolling element so it's only reachable via debug tools or turning the internet off (the latter doesn't always work because it often results in an 'oopsie wooopsie somefing went wong' error popup).
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.