Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Complexities of an infinite scroller

developers.google.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Complexities of an infinite scroller

#31

Post by happyslobro »

asurma wrote: post #26
happyslobro wrote: post #9

Complexities 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 thinki…

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.

Re: Complexities of an infinite scroller

#32

Post by vitd »

ent wrote: post #23
onion2k wrote: post #22

Earlier quoted context omitted.

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.

Also - not being able to see how far into the content you are based on the position of the scroll thumb.

Re: Complexities of an infinite scroller

#33

Post by Flow »

kinlan wrote: post #18
Flow wrote: post #16

Earlier quoted context omitted.

They are apparently aware of it at least. https://news.ycombinator.com/item?id=11882964

We are aware, and it certainly wasn't intentional. Waiting for fix in our impl of Material Design Lite (ironically before we move off it)

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?

Re: Complexities of an infinite scroller

#34

Post by happyslobro »

dzhiurgis wrote: post #30
happyslobro wrote: post #9

Complexities 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 igno…

This drives me nuts. I see two modes of breakage:

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

Re: Complexities of an infinite scroller

#35

Post by gkya »

zappo2938 wrote: post #15
crummy wrote: post #11

Earlier quoted context omitted.

I'd rather infinite scroll my twitter feed than keep clicking Next Page.

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 i…

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.

Re: Complexities of an infinite scroller

#37

Post by scotty79 »

qwertyuiop924 wrote: post #6

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?

> often making you do busy work to find content you want,

All infinite scrolls should come with a filter that lets you hide all of the stuff you are not looking for.

Re: Complexities of an infinite scroller

#38

Post by qwertyuiop924 »

kinlan wrote: post #18
Flow wrote: post #16

Earlier quoted context omitted.

They are apparently aware of it at least. https://news.ycombinator.com/item?id=11882964

We are aware, and it certainly wasn't intentional. Waiting for fix in our impl of Material Design Lite (ironically before we move off it)

Sorry for the insult... but you guys really should have tested this across browsers before it even shipped.

Re: Complexities of an infinite scroller

#39

Post by kinlan »

Flow wrote: post #33
kinlan wrote: post #18

Earlier quoted context omitted.

We are aware, and it certainly wasn't intentional. Waiting for fix in our impl of Material Design Lite (ironically before we move off it)

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 didn't replace anything, there seems to be a bug in Safari that we have to work around with a translatez() hack.. should be fixed now.
Post reply on HN