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

91–100 of 168 posts

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

#91

Post by keehun »

smoyer wrote: post #68
jakub_g wrote: post #64

Earlier quoted context omitted.

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

I mean, this is just like how Apple implements its NSTableView. You have a datasource and you implement the table's data source delegates. NSTableView itself takes care of the whole reusing views thing.

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

#92

Post by Encosia »

EGreg wrote: post #74
bduerst wrote: post #69

Earlier quoted context omitted.

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

You could solve a lot of problems with position: absolute and javascript, which you assume is on. A bigger problem is that mobile safari doesn't let you execute js during scroll. One way around that is by hsing iScroll which fakes scrolling using CSS.

You can use the touchmove event to do things while mobile safari scrolls.

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

#93

Post by ivanca »

geminitojanus wrote: post #55

Infinite scrolling like this works pretty well if you want to do scrolling for, say, search results. It's all around horrible for something like Twitter, IMO. The problem with Twitter is that it's conversational, and it's showing the newest part of the conversation at the top. So instead of having a nice conversation history: Hi! Hello to you good sir. How are you doing today. I'm fine. You get: I'm fine. How are you…

Twitter already fixed this in iOS (you always apparead where you left so you read everything in order), is just taking them a while to fix it in the browser.

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

#94

Post by yincrash »

keehun wrote: post #91
smoyer wrote: post #68

Earlier quoted context omitted.

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

I mean, this is just like how Apple implements its NSTableView. You have a datasource and you implement the table's data source delegates. NSTableView itself takes care of the whole reusing views thing.

Android's ListView also is built around view recycling. But these are both situations where the framework supports the recycling.

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

#95

Post by chc »

solve wrote: post #75
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 also wonder about "memory problems", but of the soft kind. I like to consuming "pages" of content at a time, spread between many tabs. Usually I read to the bottom of a "page", and then switch tabs. When I come back to that tab, I'm ready to go to the next page. But with infinite scrolling, I feel like I'd be re-reading content to find my exact spot I left off..

Isn't that sort of what the OP is attempting to solve? It's paginated but still scrolls infinitely.

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

#96

Post by bhrgunatha »

fiatjaf wrote: post #80
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.

This reminds me of Gabriel García Marquez's novel _The Autumn of the Patriarch_, which has no paragraphs and infinitely long sentences.

That's a great analogy - hwo did you find reading that book? I love his other books, but Autumn of the Patriarch took a LOT of mental effort.

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

#97

Post by calinet6 »

keehun wrote: post #91
smoyer wrote: post #68

Earlier quoted context omitted.

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

I mean, this is just like how Apple implements its NSTableView. You have a datasource and you implement the table's data source delegates. NSTableView itself takes care of the whole reusing views thing.

Adobe Flex had the same model and it worked quite well (despite the framework's other flaws).

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

#98

Post by navs »

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 feel with tumblr it's the combination of gifs and infinite scroll that makes it crap out. It's a far nicer experience appending /mobile/ to a tumblr url.

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

#99

Post by navs »

prawks wrote: post #44
jonshariat wrote: post #28

Earlier quoted context omitted.

If you look at the URL bar in google's example it does that as well.

The difference is that Discourse does it on a per-item basis, Google's on a per-page. A small implementation detail.

Well with discourse you want to go to a very specific comment in the thread so doing it per item is best. But that's not for every use case.

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

#100

Post by berns »

_frog wrote: post #26

I really liked Discourse's approach to infinite scrolling[1], it updates the URL as you go with the History API's replaceState() function so you can safely navigate away from the page without losing your position. [1]: http://eviltrout.com/2013/02/16/infinite-scrolling-that-work...

It's not without problems though. It breaks the incremental find in chrome. When the URL changes, the find dialog gets closed.
Post reply on HN