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.
I wonder how many people do hold and drag the scrollbar, I am so used to scrolling using a touchpad on Mac and mousewheel on PC, so I never even touch a scrollbar.
I've done many user tests and training sessions only to inwardly wince every time the user painstakingly does that. (And this on their own hardware, with their own mouse they use every day at work.)
After you explain it, they say "wow, that's neat." And then promptly forget it and start dragging the scrollbar again.
I was until recently a devoted scroll-wheel-user. But I'm starting to see the first signs of arthritis in my fingers (far too early if you ask me) and scroll wheels are becoming increasingly uncomfortable.
I've been surprised to find that dragging an old-fashioned scroll bar is actually a faster and more accurate than the wheel if you're scrolling by more than a page or so.
It is very inconvenient on a large page like this, should you need to quickly move up/down to read a related comment. If you know it, dragging the scrollbar, on the other hand, is quick to land you in the approximate target region.
I don't know if you ever used the music service Lala back before it got bought by Apple and shut down, but they had a really nice infinite scroll implementation.
When viewing your music library, the scroll bar grabber would be the correct size for how many items were in your library so grabbing it and scrolling would work right. It didn't load all X number of items you had at a time though either.
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.
This should be fixed by the browser. If mouse is hold-clicked on scrollbar and the height of the document changes. the position of the mouse should change as well.
What's the problem with that?
I'm working on an infinite-scroll widget, and I have a very specific insight into this: if you know the number of non-visible rows and their heights upfront, it can be implemented in a way that doesn't jump around. If you can estimate the heights closely, you can make the jumps less disturbing (but still noticeable in the trained eyes).
Unfortunately this is rarely the case, with a few exceptions, e.g. a spreadsheet, where you know everything upfront.
