Problems with infinite scroll

The biggest problem I have with infinite scroll is that it breaks searching within a page. If I want to find something I have to scroll down to the bottom and then wait some arbitrary time until I think enough content has loaded. Even if I know roughly where the content I'm searching for is, I can't just click to a specific page. I have to guess how far I've scrolled and hope that it's far enough. I waste time and data transfer because I'm forced to overshoot if I want to reliably find things. I can't even bookmark a specific page, so I have to repeat this tedious process every time.

I've never seen a use of infinite scrolling that wouldn't be better replaced with lazy loading of images/video.

I don't like infinite scroll but for another reason not mentioned here.

If you're browsing something that's content heavy (lots of pictures/videos) there's usually a point after a certain number of "pages" where my phone just can't take so many things loaded at once and it crashes. Not all sites have this problem, some are really bad (\cough\ tumblr \cough\) but it makes me avoid infinite scrolling sites at all costs. The ones with "Read More" are slightly better (the crash doesn't happen unexpectedly x pixels from the bottom), but still have this problem.

I thought at one point unloading the content at the top might help, but I'm not so sure now. Discourse forums do something like this, where they only load what you're viewing but it feels weird, like it's loading things it's already loaded. Sometimes I do want to scroll to the bottom of something and feel like it's all loaded everything for offline reading.

But overall by far I prefer sites/blogs that have paginated content.

For me biggest issue is if you refresh or come back (or browser app restarted), you need to start over from the beginning again. Stuff gets dynamically loaded instead of static url. I prefer pages with number in url parameter (and ui to go to next/last/... page).

Things like this are more "ephemeral", rather that static pages with good content or index you can rely on.

I dunno... I find that on most sites which implement infinite scroll, I like it.

Reddit lets me browse stuff without interruption, and it's not like I'm ever going to "go back" to somewhere earlier in the list... which has probably changed in the past 10 minutes anyways.

Shopping sites let me browse hundreds of shoes or shirts without interruption, and again it's not like I'm ever going to bookmark a segment of my search result. Same with Google Images.

It's easy enough to put footer content in the header, or in the About page or something. (How often do you use a footer anyways?)

And if you really need to start somewhere in the middle... usually filtering/sorting is a better approach anyways. E.g. for a blog, it's better to have a link to Jan 2015 articles than have a link to page 9 of posts.

I find myself mildly annoyed when I have to click through to the next page of something.

Obviously there are plenty of sites where it doesn't make sense... but I don't see it there too often since it's usually more work to program. This feels like a non-issue.

And for example, here on HN when there are too many comments it requires me to click "More" to get to page 2. Why not just auto-load them when I reach the bottom instead? If I got that far, it's more likely than not that I want to read more.

Another issue with infinite scrolling on web sites is: what happens when there's a connection problem? I've seen sites where it silently acts as if the user had reached the end of the "infinite" page, even though that's not the case. Worse, the only way to recover (once the connection is working again) is to reload the page and start once more from the beginning.

As someone with ADHD, I immediately close any website that uses infinite scroll. I will become insanely focused on that site to the point that I tune out the outside world. What begins as "oh, I'll just look at this one article" turns into at least a half hour of wasted time before I'll be able to break out of it.

I swear that DuckDuckGo had infinite scrolling for its search results, but this was not the case when I recently tried a search. Blog posts from a few years ago seems to confirm my memory that infinite scroll was the default: http://seanvwork.com/blog/duckduckgo-vs-google/

> DuckDuckGo doesn’t paginate their results like Google does. Instead, you just keep scrolling down to wade through an infinite amount of search results.

Opening up DDG's settings in incognito mode, I see that its "Auto-Load" is now a setting that is off by default:

https://i.imgur.com/yWrJ3uZ.png

I also remember that DDG fans saw infinite scroll as an advantage DDG had over Google, which was known to have rejected infinite scroll for search results: https://www.businessinsider.com/marissa-mayer-google-9-2010-...

I personally found it to be a detriment to user experience. If my query doesn't return something relevant in the first 2 pages of results, why would I want to keep going down any further -- as opposed to doing a new search? Google's pagination has an effect of protecting me from lazily scrolling through countless pages of increasingly irrelevant results, and I wonder if DDG saw the same thing in user behavior tests when deciding to make infinite scroll non-default?

> 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.

Looking at you, TechCrunch! I’ve been burned by the suddenly disappearing article too many times.

I’ve never found a site where it worked. It’s one of the most annoying experiences on the web. Especially when you need to navigate to another page just to get access to the footer for getting to “contact” or similar.

Another problem with infinite scroll is often incorrectly implemented "back" functionality in the browser. If you had scrolled down somewhere, click a link or image and then click on "back", you usually do not end up were you were before, but most often on the top of the page where you have to scroll down again to were you were. Very lousy UX.

Even if you solve this correctly by remembering the scroll position, you have to fire X ajax requests to restore the scrolling position, and have to wait until all images are renders or the content will jump wildly around.

The only infinite scroll I'm kinda OK with is DuckDuckGo. When it comes to news sites with infinite scroll, I almost never want to continue scrolling past the original article.

What I'd like to see go more than infinite scroll is sticky headers. It's one thing if your site is effectively an app, but if a site is supposed to be mostly prose then I don't want your stupid useless header in the way of screen real estate. Worse yet, you make the problem worse by having the header pop out and retract if I scroll 1px in either direction. ANNOYING.

Infinite scroll was never a good UX pattern. It was invented to keep people from leaving the page and continue to scroll on. Pagination would interrupt this, and people might leave after clicking two or three times clicking the "next page" button.

I'd argue that the author is actually under-representing the value of pagination by making an obvious mistake in implementation.

For example, under the ratings for pagination, they list: "Bad: Performance issues".

That bad rating is based on doing a dynamic post count for every page load, an approach that would only be used if someone wanted to maximize the performance penalty (or if your site/service is small enough that it simply doesn't matter if you do a new dynamic count on every page load). There's no common scenario where you aren't better off storing that post count, altered only as needed, rather than calling a new count of all posts for every single page load.

Even in a scenario of very heavy write, rare read, you're better off doing either a stored constantly incremented count or stored compromised occasional count that isn't perfectly accurate until or unless it needs to be.

Specifically the author uses this:

SELECT COUNT(*) AS total FROM posts

Instead of that, as a common scenario, let's say you have a posts table, and a comments table (which correlates comments that belong to posts by an id). You don't count how many comments each post has dynamically on every page load for a post, in the process of showing the comments. You have a counter in the post row, that increments only when a new comment is made, or decrements if a comment is removed. You pull that count at the same time you pull the core post information from the "posts" table, in the process of loading the post and then afterward pulling its associated comments.

The penalty is that you must update the post row when a new comment occurs. Assuming your service is heavier on read than write, which is almost universally the case, this is an easy win.

If all you wanted to do is track the post count, and not something further connected to it such as comments, that's also similarly trivial. There are numerous good ways to go about storing the post count until it needs incremented, rather than calculating it dynamically every page load.

All one has to do is consider a routine blog example, in which an author updates the blog once per day, and receives 1,000 or 10,000 visitors per day. There are 1,600 historical blog entries/posts spanning over four years. This article's approach is to needlessly dynamically count that over and over, perhaps tens of thousands of times per day, rather than altering and storing the count once per day when a new blog post is created. Performance bad indeed.

The primary issue with infinite scroll is not the implementation, it's the idea that a page with "infinite" content is useful or desirable to begin with.

I hate infinite scrolling because once implemented nobody cares about disabled javascript case - like reddit, the experience is broken without it - you can only see first couple of topics and can't load more.

I have some scripts I use to scrape data from FB by manually spoofing keystrokes and I shudder to think how much energy is being wasted at both ends for the amount of data I am actually trying to collect.

I always found Bing's infinite scroll for image search pretty awesome and superior and a reason to use it over Google. Haven't seen that feature much elsewhere though.

Fundamentally, scrolling indicates that you haven’t done a good job of surfacing the information that the user really needs in the first place. I see any form of scrolling as an admission of defeat on the part of the site designer.

Have terabytes of log results? Why would scrolling somehow fix that? Figure out how to fetch the stuff that matters, and put that in front of the user so they don’t have to scroll.

Scrolling should be all but unnecessary in a well designed interface.

> 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.

This absolutely isn't true at all; for example in Discourse we update the browser address bar as you scroll to reflect the current post you're viewing.

While I often like infinite scrolling, I really hate it on the Google+ Android app, because I have no way to quickly jump to the top. If I scrolled way down and want to scroll back to the top, I have to scroll manually all the way, which is a pain, or kill the app and restart it.

I'm okay with infinite scroll being the default; just don't make it the only way to navigate. Have an easy-to-find way to switch to pagination and/or query-by-example (QBE). A QBE form for a blog-type search would resemble:

     Date Range: [__/__/____] to [__/__/____]
     Word or phrase: [_____] ... [X] Search title only
     Sort by: 
        (*) Date, latest first
        (_) Date, earliest first
        (_) Title

Except for the sort-by option, they'd all be optional

What I don't like about infinite scroll is it not putting stuff in my history. Finding my way back a few days later ain't happening.

Overall though I think the pattern makes sense

A few weeks ago I was trying to find a contact page on a site that had infinite scroll (don't remember the reason or the site). The link to contact information was in the footer, which was impossible to get to with infinite scroll. Absolutely ridiculous.

Ended up having to disable JavaScript to be able to scroll down.

The thing I dislike about infinite scroll is that almost everything that has it is intended to make you addicted and compulsively scroll more, to the point where I pretty much have sworn off any app that makes it a central part of the experience.

Stop visiting websites with infinite scroll. Problem should work it self out eventually...

What if you used the cursor type with infinite scroll that put links to the page number inline so you could infinite scroll starting from any point?

Infinite scrolling exists because it raises the average time users spend on your site.

I always thought infinite scroll was the best thing since sliced bread when I first saw it in Google Reader. I still really love it for consuming my news feed.

For everything else though? Not so much.

TBH, this article is a perfect example of the formulaic, semi-clickbaity articles that I can't stand. Take the title "Stop building websites with infinite scroll", but then the article itself goes on the give some examples of when infinite scroll is appropriate. Even many of the arguments against infinite scroll feel like strawmen (e.g. "It messes up the footer." Well, seems obvious to me that putting a footer after an infinite scroll is a bad idea, but many if not most pages where you'd use an infinite scroll could do without a footer, or you could put that "footer data" elsewhere.)

All UX approaches have tradeoffs, and any UX paradigm can be implemented poorly or used where inappropriate. Bringing up some of these examples and then saying "stop using UX approach xyz" is disingenuous.

This trend is a big problem. We have to get to the bottom of it!

TL;DR don't use infinite scroll because your users can't find the footer.

Office 365's Outlook Web uses infinite scroll for listing emails, and the thing I hate about it is as you're scrolling down, it removes things from the DOM at the top. So if you want to delete a ton of emails from a service that went wonky and spammed you over the weekend, you can't click the top and shift click the bottom, because by the time you reach the bottom, the top message is gone.

This is a great example of why you should use data to drive decisions on features and not just broadly declare x or y feature is bad because you personally have gripes with it. You are not your user and you shouldn't be allowing personal feelings to cloud the debate. Decisions without data, what is this, 1996?

What are your users saying? What does the data tell you? A/B test it and find out. Do usability studies. etc etc.

Nope, infinite scroll is superior. Just there are poor implementations. Proper infinite scroll has 0 downsides.