Live data from Hacker News

Google’s suggestion for a better infinite scroll?

scrollsample.appspot.com

141–150 of 168 posts

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

#141
post #98
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.

There is a paginated mode in the settings, which is a total godsend. I dread the day when Yahoo decides to remove it.

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

#142
post #137
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...

Wouldn't it be better to use anchors? It is the same page after all... now you'll end up with thousands of duplicit entries in your history.

Not quite, the replaceState() function, as its name would imply, replaces a history item instead of creating a new one.

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

#143
post #62
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 actually very interesting. The UIKit framework that powers most iOS apps uses a similar approach in its collection and table view classes, which is one of the reasons that scrolling managed to be so smooth even on the limited hardware of the original iPhone.

Ember.js similarly has Ember.ListView[1] which was the first implementation of that idea I'd seen on the web. I had no idea that Google Wave had beaten them to the punch by so many years.

[1]: https://github.com/emberjs/list-view

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

#144

I hate infinite scrolling with a burning passion. You're reading the article and scroll down 2 pixels too far and WOP you're loading something again. Qz.com is one of the worst offenders here.

You're welcome.

In this case I called it pre-loading (it's not infinite either). You get to the end of an article and we have the next one ready for you. No need to make a choice on what to do next, just follow through if Headline is of interest.

Not perfect, but those who use it most do love it.

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

#145
My problem with infinite scrolling is that it is very hard to go straight to the last element. My example: A Flickr user with over 1000 images in their photostream. photostreams are loaded most recent first. But what if I want to see the first picture they submitted? Virtually impossible.

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

#147
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 hate reading something and not knowing the full length upfront - I want a rough gauge of how long I will be spending on an article.

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

#148
post #62
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.

Adobe's Actionscript did the same thing with their lists. Each list item was reused when it scrolled off the top/bottom with different data.

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

#149
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.

Another reason to hate it, which my wife runs across all the time on Facebook - she scrolls by dragging the scroll-thumb down with her mouse. Once she gets near the bottom, the page jumps as the extra content gets loaded, and she has to find her place again.

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

#150
post #142
post #137

Earlier quoted context omitted.

Wouldn't it be better to use anchors? It is the same page after all... now you'll end up with thousands of duplicit entries in your history.

Not quite, the replaceState() function, as its name would imply, replaces a history item instead of creating a new one.

Oh, I missed that it does that.
Post reply on HN