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.)
Complexities of an infinite scroller
21–30 of 39 posts
Re: Complexities of an infinite scroller
#22Infinite 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?
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.
Re: Complexities of an infinite scroller
#23Infinite 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?
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.…
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.
Re: Complexities of an infinite scroller
#24Infinite 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?
[deleted]
Re: Complexities of an infinite scroller
#25Is it me or is it impossible to scroll that page in Safari?
On one hand it is ironic, on another Safari still crashes after you peek into link. Half year later after the bug was introduced.
Re: Complexities of an infinite scroller
#26Complexities that the article doesn't mention: - 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…
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.
Re: Complexities of an infinite scroller
#27Is it me or is it impossible to scroll that page in Safari?
Yes, sorry about that.
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.
Re: Complexities of an infinite scroller
#28Page down failed for me. Is this really from google??
Re: Complexities of an infinite scroller
#29Infinite 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?
I'd rather infinite scroll my twitter feed than keep clicking Next Page.
I rather (live) search it...
Re: Complexities of an infinite scroller
#30Complexities that the article doesn't mention: - 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…
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.