Infinite scrolling is typically annoying, often making you do busy work to find content you want, and frankly a worse solution than just having multiple pages. So if it's also harder, why do it?
It really depends how people are using it. If people are looking for random interesting content then an infinite scroll makes sense. If you add the amount of internet time spent is using Twitter, Facebook, and Reddit (app or RES), then we can conclude that it is at a deeper level a better user interface for certain types of content. People calling something that most people just prefer without thinking about it and is mainstream 'hipster appeal' is quite ironic.
People use whatever is there. We used websites and apps before infinite scroll was a thing. The fact that some hacker types (me included) prefer this or that is mostly irrelevant to the plain user.
For something like the Facebook timeline that is unreasonable to paginate i tolerate it. But what annoys me most is when a finite list for a few hundred items has an infinite scroll.
Especially when it's a list like favorites where you would what to browse to any point equally as often (im looking at you SoundCloud).
I'm hoping that infinite scroll looses the hipster appeal sooner or later and we can implement the best solution rather than jumping on the bandwagon all the time (SoundCloud's favorites were paginated a few years ago).
The bad experiences that lead people to complain about it stem from poor implementations of the effect. Infinite scrolling done well is a great experience - if there's plenty of content loaded at the start, further content loads before you reach the bottom of the page, there's no pause or jank, and it's used it on pages where the user is browsing everything rather than looking for something specific, then it's good. Those criteria are a pretty limited scope though.
It's not just reaching the bottom that's annoying, it's stuff like trying to search with ctrl-f for content that just isn't there yet or following a link, clicking back and the viewport jumping up to the top instead of where you left.
My pet peeve: When there is a link that I need to click on the footer of a page that has infinite scroll. If you use this - please don't put a footer on your page. It will just run away from your users.
I attempted to prototype what it would be like loading the space in the full viewport so you can have an accurate scroll bar. It uses lazy loading with a deliberate 1 second delay server side.
- Browser location: When you switch from basic pagination to infinite scroll, you either take full responsibility for the navigation controls that the browser would have handled, or you accept the loss of those features on behalf of your users. When the user scrolls, will you update a page parameter in the URL? Can a user share a link to a spot deep down the list with a friend? When someone follows that link, what happens if they scroll upward? What happens when they hit the home button?
- Home button: Throw away everything and load the first page of the list. But don't forget to reuse those expensive elements. And even though you're no longer using the elements before the window position, you might as well keep them around if you expect the user to scroll downwards again.
- Back button, after leaving the list: If a user follows a link from deep within the list, and then navigates back, where do you put their view in the list? If you ignore the problem, will some browsers try to scroll to the user's last scroll position at this URL (Firefox will, and it will get it wrong if you're removing elements as the user scrolls down).
- Back button, within the list: Is this just going to scroll the user upwards a bunch of times, which is consistent with classic pagination, or will it take them to wherever they were before they entered the list, which makes sense when you consider the entire list of be a single "page"?
- Ctrl-F to find: can we still do this? Are you going replace it with a search bar? Is there any text that is shown to users, but not indexed by your search implementation? Are you searching outwards from the current position, or from the top of the list?
- Scroll bar: Are we just giving up on these, or can we agree that they are common in applications because they are actually valuable from a UX perspective? Should it accurately represent the position of the viewport in the whole list, which requires the application to know the length of the list and the size of each item, or are we going to settle for just showing the view's position within the current subset of the list, which is not nearly as useful?
- What happens when the scrollbar jumps our from under the mouse on various platforms, as elements are recycled from one end of the list to the other? Do we need to prevent that from happening?
- Should we preallocate a large number of elements with placeholder content, so that we can create DOM elements only once, if we do not have enough recyclables for the next page of content?
- What is the optimal number of elements to keep around? What about on a mobile device or a crappy web-tv with 1GB ram? On a desktop with 16gb ram? Does it vary greatly depending on the DOM rendering engine? How does the latency / bandwidth ratio affect the optimal page size?
- Do your users move around much, or do they normally only browse forward, slowly, and then leave? Are the rare users who do move around alot likely to be significantly more valuable to you than the simple users?
- API request caching headers: if the user scrolls back, do they actually need to make another HTTP request for content that they just saw recently? If they do make that request, what happens when there is a new item to insert in the list?
TL;DR Do not take it for granted that infinite scroll is even a good idea for your content. I've built a bunch of these over past decade, not just on web, and now I cringe a little when a client quips "oh, and let's make it infinite-scroll, not paginated, ok?"
We should definitely insist on an A/B test between infinite scroll and pagination when we are going to introduce it. I am aware that that A/B test would be a little more difficult than usual to implement, since A and B might not span the same URL structure.
Lots of good points here! This article (and the implementation) were born out of the frustration with the lacking performance of most infinite scrollers. We were aware of some of the issues you list (I’m not going to claim we thought of everything ;) ), which is also the reason why we are not providing a library for people to use. Too much left to do right.
> Navigation controls
Definitely something that needs thinking and that we intentionally didn’t address here.
> Ctrl+F
We were think on how to solve this, but we weren’t able to come up with anything using the tools the platform provides currently. Maybe a future API will help here.
> Scrollbars
I thought we did a pretty good job on the scrollbar. You can still click the scrollbar indicator and drag it around to quickly jump from position to the other. It’s not AS accurate, but still useful and doesn’t diminish UX imo.
> Jumping scrollbar
Should barely happen! We are using a sentinel element to define the length of the runway, not the elements themselves to minimize jumping. I think it can only happen if elements grow drastically in height when going from tombstone to actual content.
> “Adaptive DOM pool”
This is definitely an improvement that could be made. Currently we just maintain N elements and N tombstones in memory. N could dynamically adapt to the capabilities of the device.
> Caching
How much caching is utilized is very much up to you. If the API doesn’t provide good caching headers you could implement that yourself in the data source. I think this falls outside of the technical scope of the scroller itself.
A faraway sentinel element is pretty clever, I never thought of that.
Anyway, as long as there are legitimate cases where infinite scroll is superior to click-to-page, I am glad that someone is focusing on this problem and treating it seriously. When you really stop to consider the problem, you start to see that it has all of the complexity of a one dimensional scenegraph over dynamic terrain, in a game where the "player" can warp and fly at high speeds, but can't reasonably store the full dataset locally.
I've noticed CTRL+F is occasionally broken these days (match found, but not visible) and was thinking perhaps its the time for browser vendors to introduce a new way to search pages for users?
a.i. CTRL+F to search current state, then click on option to search in the way that website implements and then perhaps use global search (optional).
I'm sure graybeards will argue this breaks web in some way, so pardon my ignorance.
1. When a search engine indexes something dynamic that has changed by the time I visit the page, and
2. When some part of the UI is in the DOM, but not visible.
#1 could probably be solved by judicious use of <aside> on the part of developers, and by SEO penalties imposed on sites that update indexed content without inviting a crawler over to see it within a timely manner.
As for #2, I avoid this problem in React by imposing a rule in the coding standards: Do not hide elements. Omit them from a render function when you don't need them. This idea of keeping a stash of recyclable elements complicates that a little.
What browser vendors could do to help, is identify non-visible elements and omit them from the Ctrl-F search index. They are probably already identifying invisible elements in order to prune them from the renderer's view of the DOM tree. I wonder how hard it is to submit a pull request to Chromium?
Gee. Google code not working on non-google browsers. What a surprise.
Speaking as a firefox user, I'm lucky if google docs even loads, let alone works properly. Yet a another example of google talking out of their ass about "supporting web standards"
What are you gaining by replacing the native scroll functionality?
Are you trying to add "standard Android scrolling inertia" or something? I mean you must be trying to change something, or will I not notice it when it's working?
We currently can’t scroll on the body element due to a limitation in Chrome, where an empty body layer is not being optimized. So we are scrolling in an element. However, that usually requires setting `-webkit-overflow-scrolling: touch;` so that you can scroll as usual on iOS. However, that in turn has a lot of hidden implications (like squashing layers, etc. Don’t know the details right now), that make performance suffer greatly.
AFAIK, Safari will change their scroll-on-element behavior. Let’s see what the future brings.
For a React implementation, look no further than react-virtualized (https://github.com/bvaughn/react-virtualized). Performant, great featureset, and one of the most accessible, responsive maintainers I've ever seen in an open source project.
Hm. As far as perceived performance, I recently wrote a proof-of-concept library using a timer and calculating viewport intersection of an element. It feels less annoying than a registered scroll event, although I did not do any instrumented performance comparisons. (The point of the library was progressive enhancement, not performance.)
