1. 14

  2. 15

    The answer of course is, yes, it’s technically possible to implement the one infinitely scrolling site I’ve ever used that doesn’t completely suck:

    • Can the user hit “back” and return to the exact same place? Yes. When within a topic, it uses history.replaceState to keep track of where you are, and it will use that to return you if the page reloads.

    • Is there paging for when the JavaScript breaks? Yes. Non-JavaScript users get a completely different page, with old-school pagination.

    • Does the page have a footer? No (unlike every other question, answering in the negative to this one is considered good). If someone uses a theme component to add one, they get what they deserve.

    • Can a keyboard user access all other content on the page? Yes. The infinitely-added content is the last content on the page. Nothing is after it in the DOM.

    • Can you share a URL to a specific place on the page? Yes. See item 1.

    • Can a user easily jump ahead a few “pages” to quickly get to content much further down the list? Yes. That’s what the thing on the side does.

    • Does the memory footprint of the page dramatically increase after just a couple new “pages?” No. It removes items from the DOM when they go off-screen.

    • Is there a way to disable automatic infinite scrolling and lean on standard paging? No. Not other than disabling JavaScript.

    • Have you conducted any user tests? Yes.

    • Are you satisfying a use case that has come from research or user request? Yes. Infinite scrolling is employed to encourage people not to jump ahead to the last page.

    • Do you have any analytics/tracking to measure success? Yes. Users have complained about it, but it’s partially feeding into the anti-spam system, so it’s easy to justify.

    … but have you looked at Discourse’s code?! They not only reimplement parts of the browser, they reimplement parts of Ember.JS because the stock code is too slow. They have to implement debouncing for history.replaceState because updating it while scrolling caused scrolling to stop in Chrome. And the reusing DOM nodes thing is also pretty complicated. And there are still known issues.

    Discourse is slow enough that opening a Discourse page causes my laptop fan to briefly spin up. Once it’s running it’s fine, but it’s noticeable enough that I figure infinite scrolling is simply not worth the implementation complexity of doing it right.

    1. 5

      Looking at that from an iPad now, I’m having a couple of issues:

      • I don’t see the URL change as I load more content, and reloading takes me to the top. Maybe iOS Safari doesn’t support replaceState? Luckily, opening a thread and hitting back takes me to where I was, but if I’m leaving the page open in a background tab for a while and it gets cleaned out of RAM, I’ll lose my place. That’s pretty bad.
      • When scrolling to the bottom of the screen on iOS, the content “rubber bands” as it scrolls past the screen and then up again. Continuing to do the scroll gesture continues the rubber banding. The page doesn’t start loading more content until the rubber banding has completely stopped. To scroll a couple pages down, I have to scroll down, stop scrolling, wait for the animation to come to a complete halt, wait a moment for the page to notice, wait for the new content to actually load, resume scrolling, reach the end again, wait for the animation to end again, etc.

      Those two issues compound: if you’ve been working through a dozen pages, and the page ends up reloaded and you’re at the top again, scrolling quickly through those dozen pages would be infuriating.

      It also has the in-page search issue mentioned by craftyguy.

      Discourse does it better than most, but I’m not entirely sure it’s possible to build a good infinitely scrolling list which works better than pagination in every browser on every device.

      Yes. Infinite scrolling is employed to encourage people not to jump ahead to the last page.

      I have to ask, why is that desirable? I mean, I get why you may not want a “last page” button, but if I want to find content from a month ago, why is it desirable to discourage me from finding that content?

      1. 2

        I’ve written a longer-form response as a separate post. https://notriddle-more-interesting.herokuapp.com/D35K4ZCCNG6RB

        1. 1

          I don’t see the URL change as I load more content, and reloading takes me to the top.

          The latest view and the in-topic view are different. The in-topic view is the one that uses replaceState.

          The latest view doesn’t do permanent URLs because it’s constantly shifting around every time something gets bumped anyway. I’m not entirely convinced that this is the right trade-off to make, but if you’ve ever bookmarked page 5 and had the stuff in page 5 change out from under you, I’m sure you can understand why they don’t bother.

          When scrolling to the bottom of the screen on iOS, the content “rubber bands” as it scrolls past the screen and then up again.

          Yeah, that I’ll agree is an actual problem………. I’ve got nothing. No idea whatsoever how to solve it. Safari is throttling your onscroll events, and they’re probably right to do so considering the fact that they want to make sure it doesn’t stutter while it scrolls. I really have no idea what either group could possibly do about this.

          I have to ask, why is that desirable?

          The latest view and the in-topic view are different. I guess it doesn’t make much sense for the latest view to restrict it like that (though I’m pretty sure Discourse team would point you at the software’s own search functionality, which has a way to filter by date, rather than fighting with the pagination system).

          But the reason it’s desirable to have people read the entire thread instead of jumping to the bottom? Encouraging people to read stuff is kind of core to the whole Discourse philosophy, and it’s the cool part that I want to see pushed elsewhere.

      2. 9

        They are missing my biggest pet peeve with infinite scroll (well, besides having no “no JS fallback”): in-page searching.

        In nearly every application of infinite scroll I have seen, if you want to search for something in the page, you need to 1) search for your thing, 2) scroll down to the bottom, 3) let the next ‘page’ load, 4) goto #1 and ignore any previous false positives (repeatedly as you do this madness over and over again).

        1. 8

          Excellent points, all of them. I do not understand why anyone prefers infinite scroll over pagination or any other mechanism. It’s impossible for many disabled users to use at all, and for users without disabilities it still falls over in common use cases (like the back button).

          1. 5

            People do not consciously prefer it, but it probably rated higher in time-on-page metrics.