If you are someone who actually likes to have some control over what is happenning on your computer, and if you want to have some organization when you are dealing with a list of things that is pretty long - hundreds/thousands or more items - then pagination is useful. And continuous scroll is tempting/seductive, but ultimately flawed.
Google’s suggestion for a better infinite scroll?
131–140 of 168 posts
Re: Google’s suggestion for a better infinite scroll?
#132my suggestion for infinite scroll: make it finite.
Re: Google’s suggestion for a better infinite scroll?
#133I would like to add a suggestion for better infinite scroll: ban it.
Re: Google’s suggestion for a better infinite scroll?
#134Earlier quoted context omitted.
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..
That's a problem that can be solved by paginating the data and using the history api to push the page state on the stack while the UI seamlessly loads the pages together.
Which it actually does. Look at the URL.
Re: Google’s suggestion for a better infinite scroll?
#135Earlier quoted context omitted.
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.
Is it? I was going to add it to the list, but the Adapter that manages the data actually generates (and caches) a View for each element. Is there something I'm not understanding?
Re: Google’s suggestion for a better infinite scroll?
#136Earlier quoted context omitted.
Android's ListView also is built around view recycling. But these are both situations where the framework supports the recycling.
Is it? I was going to add it to the list, but the Adapter that manages the data actually generates (and caches) a View for each element. Is there something I'm not understanding?
Yep it is. The Adapter will generate and cache a view for each item - but once the view moves off the screen, the adapter will reclaim/recycle that view, and the next item to request a view will be given the recycled view. In effect it is identical to the ios or flash list model.
Re: Google’s suggestion for a better infinite scroll?
#137I 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?
#138I 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...
If you look at the URL bar in google's example it does that as well.
The difference is that it doesn't break the back button! Clicking back takes me back to HN, not back a page.
Re: Google’s suggestion for a better infinite scroll?
#139Earlier quoted context omitted.
Is it? I was going to add it to the list, but the Adapter that manages the data actually generates (and caches) a View for each element. Is there something I'm not understanding?
Yep it is. The Adapter will generate and cache a view for each item - but once the view moves off the screen, the adapter will reclaim/recycle that view, and the next item to request a view will be given the recycled view. In effect it is identical to the ios or flash list model.
Cool ... I knew I was passed back a "convertView" sometimes but didn't realize it was recycling them.
Re: Google’s suggestion for a better infinite scroll?
#140I 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.
And I thought my DOMbuffer idea would be new. Did you investigate yourself or did Google publish some technical papers about Wave ?
ps: reminds me of Google Maps tiles.