Paging through lists or tables has always struck me as an awkward pre-GUI throwback necessitated by the limited bandwidth of the early web. Scrolling is generally superior to paging, providing more convenience, flexibility, and feedback to the user; plus it’s more standardized. I generally recommend loading all of a list into a page or scrollable pane whenever bandwidth allows, rather than using paging.
Endless scrolling tries to have it both ways, handling the bandwidth problem while trying to have some of the advantages of scrolling. However, while endless scrolling solves some of the weakness of paging relative to scrolling, it introduces new problems, so I’m not sure it’s a better alternative.
Breaks scrollbar expectations. The biggest problem is that endless scrolling looks like a normal scrollbar, but doesn’t act like it. A proliferation of endless scrolling ruins scrollbars for normal use. For example, users won’t know when they can and can’t estimate total content from the scrollbar’s appearance.
Breaks position estimation. If users want to go back to a previously seen item, it’s difficult to know how far back to scroll since the corresponding position of the scrollbar slider changes as new content is loaded. With normal scrollbars, things scrolled ¼ from the top stay ¼ from the top. With paging, things on Page 4 stay on Page 4.
User limited to moving a fixed block of items ahead. If the user knows approximately where the desired list item is in the list (e.g., remembers from a previous visit), the user is nonetheless compelled to navigate to it by incrementally and slowing adding new items to the bottom of the list through continuous scroll-downs. Normal scrolling allows the user to randomly access any point on the list almost instantly. Paging generally allows some broader and more flexible access (e.g., jump to the end) than endless scrolling.
Content lost when navigating away. When the user navigates back to an endless scrolling page, typically content reloads from the beginning, resulting in users losing their place in the list. When one navigates back to a paged list or normally scrolling list, they are return to the point in the list where they left.
I believe we need a separate control for endless or virtually endless lists. Such a control could leverage interaction conventions from the normal scrollbar, but should appear distinct from it. It should provide some reference to location in the list (e.g., timestamp, coordinates, relevance rating) to support position estimation. It should allow jumps of arbitrary size to other positions, and preserve the current position when the user navigates to a different page. Maps are one place I’d like to see such a control developed, where scrolling is truly infinite (or circular, really).
However, I don’t see it as a particularly urgent need. With few exceptions (such as maps), endless paging/scrolling is sign of a bad design. If you have so much content that you can’t load it all at once in a normally scrolling list, then maybe you’re giving the user too much content. You’re expecting too much work from them to scroll and scan through all that. You need a way to better organize or filter the content than dumping it into a humungous list and let the user manually and tediously sift through it all.