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

Google’s suggestion for a better infinite scroll?

scrollsample.appspot.com

Post reply on HN
Print view View original

61–70 of 168 posts

Re: Google’s suggestion for a better infinite scroll?

#61

Post by joveian »

davb wrote: post #38

I'm surprised at how many people here seem to like infinite scroll. I personally can't stand it. Imagine having a book where no matter how much you read, it never seems to end. No milestones, no sense of progress. Just page after page after page. It just feels... icky.

I think the main problem is that somehow 10 or 20 items on a page got to be standard and that is just annoying. 200 items on a page seems like a good number to me. Scrolling is often easier, but I want it to stop.

OTOH, there are many, many ways to mess up pagination UI as well. Not showing how many pages there are is one that often annoys me, because one time I will go through a bunch of pages of stuff is if I am quickly visually scanning to find something I saw before but couldn't track down with search or bookmarks all that quickly for some reason. If I know what I am looking for is on one of 15 pages then there is a good chance I can find it quickly, but with 50 pages it might be more effective to keep trying my luck at search (or just give up).

Re: Google’s suggestion for a better infinite scroll?

#62

Post by smoyer »

jakub_g wrote: post #59

I would feel kind of okay with infinite scroll if it wasn't creating memory problems. Especially on image-heavy (tumblr) / DOM-heavy (facebook) pages. If I browsed the web in 90s mode (one window, one page opened) that would maybe work, but when I have dozens of tabs opened, youtube playing in background and I start browsing an endless memory-hungry page, my laptop (3 GB RAM) starts dying. Another issue is the one me…

Google's Wave used (and reused) a fixed number of DOM elements that were filled by fly-weights containing the data to be shown on that page. While the scroll bar showed the appropriate position in the thread, there was a limited amount of data for the items above and below the visible set, and an even more limited number of DOM elements that could be filled with data.

Re: Google’s suggestion for a better infinite scroll?

#64

Post by jakub_g »

smoyer wrote: post #62
jakub_g wrote: post #59

I would feel kind of okay with infinite scroll if it wasn't creating memory problems. Especially on image-heavy (tumblr) / DOM-heavy (facebook) pages. If I browsed the web in 90s mode (one window, one page opened) that would maybe work, but when I have dozens of tabs opened, youtube playing in background and I start browsing an endless memory-hungry page, my laptop (3 GB RAM) starts dying. Another issue is the one me…

Google's Wave used (and reused) a fixed number of DOM elements that were filled by fly-weights containing the data to be shown on that page. While the scroll bar showed the appropriate position in the thread, there was a limited amount of data for the items above and below the visible set, and an even more limited number of DOM elements that could be filled with data.

That's interesting. So whenever I scrolled a lot down, and wanted to scroll to the beginning, the related data was re-fetched? Or it was stored in the data model, but just not displayed in the DOM?

Re: Google’s suggestion for a better infinite scroll?

#65

Post by highace »

davb wrote: post #38

I'm surprised at how many people here seem to like infinite scroll. I personally can't stand it. Imagine having a book where no matter how much you read, it never seems to end. No milestones, no sense of progress. Just page after page after page. It just feels... icky.

It's worse than that. At least with the book you get to turn the page. This is more like having a book, and knowing there's other pages, but you can never get to the bottom of the page you're on.

Re: Google’s suggestion for a better infinite scroll?

#66

Post by eieio »

davb wrote: post #38

I'm surprised at how many people here seem to like infinite scroll. I personally can't stand it. Imagine having a book where no matter how much you read, it never seems to end. No milestones, no sense of progress. Just page after page after page. It just feels... icky.

The xkcd on infinite scrolling is very relevant here[1]. It even uses the same book comparison!

I don't hate infinite scrolling as much as I used to, but I think that's just because I'm not a heavy user of any sites that have infinite scrolling.

[1] https://xkcd.com/1309/

Re: Google’s suggestion for a better infinite scroll?

#67

Post by dubfan »

georgemcbay wrote: post #49
davb wrote: post #38

I'm surprised at how many people here seem to like infinite scroll. I personally can't stand it. Imagine having a book where no matter how much you read, it never seems to end. No milestones, no sense of progress. Just page after page after page. It just feels... icky.

I wish to join your infinite scroll haters club. To paraphrase Jeff Goldblum's "Ian Malcolm" in Jurassic Park: "Yeah, but your front-end developers were so preoccupied with whether they could that they didn't stop to think if they should." I personally find infinite scroll to be far worse than cleanly paginated pages in every regard. YMMV, I guess.

Every time I've witnessed infinite scroll being implemented into a project I've been involved with, the decision was not made by the developers.

Re: Google’s suggestion for a better infinite scroll?

#68

Post by smoyer »

jakub_g wrote: post #64
smoyer wrote: post #62

Earlier quoted context omitted.

Google's Wave used (and reused) a fixed number of DOM elements that were filled by fly-weights containing the data to be shown on that page. While the scroll bar showed the appropriate position in the thread, there was a limited amount of data for the items above and below the visible set, and an even more limited number of DOM elements that could be filled with data.

That's interesting. So whenever I scrolled a lot down, and wanted to scroll to the beginning, the related data was re-fetched? Or it was stored in the data model, but just not displayed in the DOM?

I think the message tree was stored in its entirety assuming it wasn't too big. But each of these messages was significantly smaller than the memory footprint of the DOM element in which they would have been displayed. The efficiency of putting new content into a DOM element at the bottom of the list (below the visible content) and reordering it within the parent (so it was at the top was significantly faster than deleting that bottom DOM element and adding a new child element at the top.

Give me a few minutes and I might be able to find the Google I/O talk where this was described ... Wave used GWT to generate its Javascript but it's a great technique for browser-based clients regardless of how you end up with your Javascript.

The method of "recycling" DOM elements is described in minutes 20-25 of this video: https://www.youtube.com/watch?v=T_CLzgEL7FA. I can't find the reference, but I also remember hearing that they used some preloading to make other operations on the screen react much faster (e.g. loading the first 25 messages for each wave headline in the list).

Re: Google’s suggestion for a better infinite scroll?

#69

Post by bduerst »

jakub_g wrote: post #59

I would feel kind of okay with infinite scroll if it wasn't creating memory problems. Especially on image-heavy (tumblr) / DOM-heavy (facebook) pages. If I browsed the web in 90s mode (one window, one page opened) that would maybe work, but when I have dozens of tabs opened, youtube playing in background and I start browsing an endless memory-hungry page, my laptop (3 GB RAM) starts dying. Another issue is the one me…

I've thought about this before - where you have a 2D array of images with infinite scroll in all directions.

You need to track the scroll position, and kill the elements that are scrolling away as you create the new elements in the direction you are scrolling - with the entire purpose of creating enough cached images so that it is seamless to the user.

The problem is that the scroll position changes back when you kill the old elements, so you need to keep a running tally of the matrix somewhere to track the user's position.

Re: Google’s suggestion for a better infinite scroll?

#70

Post by couchand »

joveian wrote: post #61
davb wrote: post #38

I'm surprised at how many people here seem to like infinite scroll. I personally can't stand it. Imagine having a book where no matter how much you read, it never seems to end. No milestones, no sense of progress. Just page after page after page. It just feels... icky.

I think the main problem is that somehow 10 or 20 items on a page got to be standard and that is just annoying. 200 items on a page seems like a good number to me. Scrolling is often easier, but I want it to stop. OTOH, there are many, many ways to mess up pagination UI as well. Not showing how many pages there are is one that often annoys me, because one time I will go through a bunch of pages of stuff is if I am qu…

The worst offender here is Salesforce. Ten items by default, click "Show more" to see ten more goddamn items.
Post reply on HN