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

121–130 of 168 posts

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

#121

Post by User8712 »

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

Agreed.

Remember the old printers, and how the paper had holes on the sides, and was just one continuous sheet? Imagine if magazines were printed that way, so you didn't flip pages, but instead you just kept folding back a part of the endless paper and reading on.

That's how I feel with infinite scroll. I like flipping magazine pages like I enjoy clicking links. I don't know what it is exactly, it just feels more natural, and organized.

There are exceptions though. If I'm using an iPhone, endlessly scrolling through my inbox, or song list (with the ability to tap to a particular letter), works incredibly well. Then again, touch screens in general feel great with infinite scroll. It's a tricky situation, and really depends on the device and content.

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

#122

Post by dclara »

jonshariat wrote: post #6
lubujackson wrote: post #5

It still jumps around if you hold and drag the scrollbar - always my complaint with these.

Ditto. I wonder if that can be remedied by preloading a page or two and holding it for when the user hits the next page

Good idea. I think it's better than infinite scroll, but cache one page before and one page after to improve the page loading more smoothly using AJAX, just don't push me to the next page until I hit the "next" button.

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

#123

Post by Encosia »

EGreg wrote: post #120
Encosia wrote: post #92

Earlier quoted context omitted.

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

Really? http://stackoverflow.com/questions/10482227/javascript-dom-c...

Looking back at the code that I was thinking of, it looks like I was using requestAnimationFrame to do the actual DOM manipulation (based on a variable that was updated in touchmove). Maybe Mobile Safari still allows DOM manipulation during those animation frame callbacks, even if touchmove is happening?

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

#124

Post by snogglethorpe »

kevingadd wrote: post #20
lubujackson wrote: post #5

It still jumps around if you hold and drag the scrollbar - always my complaint with these.

I tend to dislike pure infinite scrolling and instead prefer on-demand loading. With on-demand loading you would set the virtual height of the scrollable area to the height necessary to show all (or a huge chunk of) your data, and then page in chunks of the data as it approaches the viewport. Then dragging the scrollbar works, and touch scrolling shows a reasonable representation of how much data is left.

The problem is that many of the places they use infinite scrolling have such large datasets that doing this would make the scrollbar borderline useless for small movements (move back half a page or 1-2 pages) -- which probably account for 99% of scrollbar uses in this context. Google search for "cat"...

Of course if you actually advanced extremely far in a typical "infinite" scrolling view, the scrollbar would similarly become pretty useless, but in practice very few people actually scroll all that far, so it seems better to optimize for that case.

They could meet halfway by making the "scrollbar readjustment" chunk size somewhat larger than the "load new data" chunk size, so you get the on-demand loading efficiency of the latter with fewer scroll-bar jumps, but I don't think they could make the former too large without creating more usage problems than they're solving.

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

#126

Post by mikaraento »

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.

That's right: a) you don't get scroll events until the scroll has finished, b) you do get touch events that drive the scroll (but nothing during the inertial part), c) the appearance of the page is not updated until the scroll has finished.

You can get around this by using programmatic scrolling (e.g., iScroll, zynga-scroller) but you'll never get quite as nice scrolling as with the native behaviour.

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

#127

Post by mikaraento »

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 it's a good fit on mobile.

The mobile browser performance is still much lower than on the desktop, so you don't want to render too large a DOM at once.

Loading a new page over the network can easily take 10s, if you need to reactivate the 3G connection from a low-power state. Of course you can use a single-page-app approach to help that bit.

Scrolling in one direction is one of the easiest (and most fun) interactions you can do on a touch screen - clicking is much harder.

Post reply on HN