11 ms·

Complexities of an infinite scroller

56 points by PhilipA 10y ago

martin-adams 10y ago
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. http://www.meda.co.uk/sandbox/infinitescroll/list.php http://www.meda.co.uk/sandbox/infinitescroll/list.php Fun project, but very challenging to make it work it fast on a mobile device. Basically it adds placeholder elements and adds the items when they get close to the viewport. It did have the advantage that you can link to a specific product in the list. http://www.meda.co.uk/sandbox/infinitescroll/list.php?product=100 http://www.meda.co.uk/sandbox/infinitescroll/list.php?produc...
- zappo2938 10y ago
  OCD kicking in. Try setting the header box-sizing property to border-box.
tlammens 10y ago
Is it me or is it impossible to scroll that page in Safari?
- Flow 10y ago
  It's not just you. Safari 9.1.1 on El Capitan.
- qwertyuiop924 10y ago
  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"
  - Flow 10y ago
    They are apparently aware of it at least. https://news.ycombinator.com/item?id=11882964 https://news.ycombinator.com/item?id=11882964
    - kinlan 10y ago
      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)
      - Flow 10y ago
        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?
        kinlan 10y ago
        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.
      - qwertyuiop924 10y ago
        Sorry for the insult... but you guys really should have tested this across browsers before it even shipped.
- lazyjones 10y ago
  Same here, Safari 9.1.1 on OS X 10.11.5, uBlock and ABP installed.
- dzhiurgis 10y ago
  On one hand it is ironic, on another Safari still crashes after you peek into link. Half year later after the bug was introduced.
- asurma 10y ago
  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.
coolmitch 10y ago
For a React implementation, look no further than react-virtualized (https://github.com/bvaughn/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.
- deleted 10y ago
  [deleted]
qwertyuiop924 10y ago
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?
- deelowe 10y ago
  Thank you. Infinite scroll sucks.
  - phatfish 10y ago
    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).
- crummy 10y ago
  I'd rather infinite scroll my twitter feed than keep clicking Next Page.
  - zappo2938 10y ago
    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.
    - gkya 10y ago
      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.
happyslobro 10y ago
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 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?"
EGreg 10y ago
If you're going to do infinite scroll, at least make it fun and introduce parallax scrolling fx. Especially on mobile, whoo! Not joking: http://www.creativebloq.com/web-design/parallax-scrolling-1131762 http://www.creativebloq.com/web-design/parallax-scrolling-11...
- gkya 10y ago
  Oh, cat litter with perfume.
BostonEnginerd 10y ago
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.
romaniv 10y ago
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.)
swah 10y ago
Page down failed for me. Is this really from google??

56 points by PhilipA 10y ago

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. http://www.meda.co.uk/sandbox/infinitescroll/list.php http://www.meda.co.uk/sandbox/infinitescroll/list.php Fun project, but very challenging to make it work it fast on a mobile device. Basically it adds placeholder elements and adds the items when they get close to the viewport. It did have the advantage that you can link to a specific product in the list. http://www.meda.co.uk/sandbox/infinitescroll/list.php?product=100 http://www.meda.co.uk/sandbox/infinitescroll/list.php?produc...

zappo2938 10y ago
OCD kicking in. Try setting the header box-sizing property to border-box.

tlammens 10y ago

Is it me or is it impossible to scroll that page in Safari?

Flow 10y ago
It's not just you. Safari 9.1.1 on El Capitan.
qwertyuiop924 10y ago
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"
- Flow 10y ago
  They are apparently aware of it at least. https://news.ycombinator.com/item?id=11882964 https://news.ycombinator.com/item?id=11882964
  - kinlan 10y ago
    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)
    - Flow 10y ago
      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?
      - kinlan 10y ago
        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.
    - qwertyuiop924 10y ago
      Sorry for the insult... but you guys really should have tested this across browsers before it even shipped.
lazyjones 10y ago
Same here, Safari 9.1.1 on OS X 10.11.5, uBlock and ABP installed.
dzhiurgis 10y ago
On one hand it is ironic, on another Safari still crashes after you peek into link. Half year later after the bug was introduced.
asurma 10y ago
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.

coolmitch 10y ago

For a React implementation, look no further than react-virtualized (https://github.com/bvaughn/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.

deleted 10y ago
[deleted]

qwertyuiop924 10y ago

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?

deelowe 10y ago
Thank you. Infinite scroll sucks.
- phatfish 10y ago
  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).
crummy 10y ago
I'd rather infinite scroll my twitter feed than keep clicking Next Page.
- zappo2938 10y ago
  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.
  - gkya 10y ago
    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.

happyslobro 10y ago

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

EGreg 10y ago

If you're going to do infinite scroll, at least make it fun and introduce parallax scrolling fx. Especially on mobile, whoo! Not joking: http://www.creativebloq.com/web-design/parallax-scrolling-1131762 http://www.creativebloq.com/web-design/parallax-scrolling-11...

gkya 10y ago
Oh, cat litter with perfume.

BostonEnginerd 10y ago

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.

romaniv 10y ago

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

swah 10y ago

Page down failed for me. Is this really from google??