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.
Google’s suggestion for a better infinite scroll?
141–150 of 168 posts
Re: Google’s suggestion for a better infinite scroll?
#142I 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.
Re: Google’s suggestion for a better infinite scroll?
#143I 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.
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.
Re: Google’s suggestion for a better infinite scroll?
#144I 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.
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?
#145Re: Google’s suggestion for a better infinite scroll?
#146More explanation on their blog: http://googlewebmastercentral.blogspot.com/2014/02/infinite-...
I could not find what was new witouth explanation.
Re: Google’s suggestion for a better infinite scroll?
#147I'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.
Re: Google’s suggestion for a better infinite scroll?
#148I 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?
#149I'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.
Re: Google’s suggestion for a better infinite scroll?
#150Earlier 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.