[Isomorphic]

So again, free-scrolling through this many rows doesn't make sense from either a usability or database performance perspective. To hop to the end, the user can reverse sort; for anything else, using a filtering interface makes much more sense than a scrolling interaction in which each pixel moved corresponds to more than 1000 rows traversed.

[tomhj]

True, the user can reverse the sort. But the relative position of the scroll "thumb" is not reflecting the reality of the dataset - and that is a usability problem IMHO. And even if the user does continue scrolling down, the totalCount will continue to increase and eventually the ListGrid will break.

I think I can live with things the way they are now - just putting in my $.02 that the completely virtualized scrolling system would be ideal.

[Isomorphic]

With progressive scrolling you can pick however far you want to allow the user to jump scroll, so by advertising a dataset length of eg 10k records, you can show a minimum size thumb and allow limited jump scrolling into the beginning of the dataset.

Beyond that size, the scrollbar and thumb cannot represent the relative page and dataset size (because this require a sub-pixel thumb) so show it externally if it's important.

[tomhj]

Positioning within the data via dragging the "thumb" will always be approximate. No one will expect pin point accuracy to scroll down to row 1,245,345 out of 1,500,000 for instance.

But most users do expect to be able to scroll 1/2 or 3/4 down with the thumb and get to roughly 1/2 or 3/4 of the data set. If it's +/- 1,000 rows because one scrolling pix equals 1,000 rows within a huge dataset - that is fine.

[Isomorphic]

Right, that makes sense if you ignore the part about it being terrible for server performance and less useful than filtering interfaces.

[tomhj]

You are making (invalid) assumptions about my backend and whether my users are willing to wait 10 seconds to see their data.

And yes, my app does also support filtering - but it doesn't stop them from trying to scroll all over the place.

[Isomorphic]

That is possible, although we've seen a wide variety of database systems and other data stores (relational and non-relational) and performance characteristics seem pretty consistent :)

Another possibility is that you haven't thought hard enough about a good filtering interface, or even an alternative, domain-specific paging mechanism that would be more usable than a scrollbar with this data volume, and faster.

Regardless, if you think it's worthwhile to build in scrollbar support for paging through this size of dataset, consider Feature Sponsorship.

[tomhj]

My application does have filtering capability - but it doesn't stop users from trying to scroll all over the place.

Through wonderful tools like GWT and SmartGWT, we've been able to convert full featured desktop applications to run in a browser. But that hasn't changed the users expectations about what they can do with such a rich interface.

Point well taken about Feature Sponsorship. I'll pass that along.

[sjivan]

I got that link off the GWT project page, specifically:

http://code.google.com/p/smartgwt/wiki/NightlyBuilds_and_MavenRepository

Updated the URL, thanks.