When is it appropriate to use endless paging in a web application (e.g. auto load or a "see more" link)?
Examples
This also creates a few issues for the user:
What are the pros and cons to this approach and how can the problems be mitigated?
In short - it's appropriate when the main use case of the page is "light browsing", such as in Flickriver, when sharing (email, etc.) only one thing on the page is irrelevant and when SEO matters less.
When I say "light browsing" I mean the user is basically just scrolling, looking for interesting things, without the need to commit or return to a specific item (which is what most people do on Flickriver).
Pros:
Cons:
Mitigation:
It sounds like a good fit for such a page would not need to mitigate the cons, since they don't interfere with the common use cases of it. If you still have a real reason and want such a pattern, you can for example supply an alternative navigation that allows the user to "bookmark" locations on the page and then jump between them, try to hijack the back button to scroll up this much etc.
Using the back/forward buttons shouldn't be an issue for a good implementation of continuous scrolling. It's possible to mitigate the issue by updating the URL fragment as you go. For example as I scroll down in forrst.com I go from:
to
giving URLs that work with back buttons.
I believe we need an alternative to paging for endless or virtually endless lists of items, and I believe such an alternative should have all the advantages of scrolling and leverage interaction conventions from the normal scrollbar. However, the endless scrolling that I have seen ain’t it. It is almost always worse than paging for just about every likely application you may come across. The disadvantages:
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 one block of list 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 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 returned to the point in the list where they left.
Until there is a design that addresses all these issues while overcoming the problems of paging, I’d stick to paging. Or better: don’t present a virtually endless list. With very few exceptions (maps come to mind), 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 single-page 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 just dump it into a humungous list and let the user manually and tediously sift through it all.
For example, for users conducting a sufficing search, you could show a sample of a whole lot of items (say, 500 photo thumbnails) in a single scrolling page. The sample could be:
Your best shot at what the user is looking for. Supplement the sample with links for alternative interpretations of what the user might be looking for, which each present a different sample of items.
An attempt to capture the diversity of what the user might be looking for. Each item could then include a link for “more like this” that each would show another sample based on similarity to that item.
Almost never, users may have a harder time orienting themselves but that is an easily solvable with horizontal landmarks indicating which page.
SEO wise it's a no brainer- if you are relying on bots following your pagination and not using XML site maps, you are not doing proper SEO. If anything it should increase user interaction -the whole point of SEO.
It's appropriate when paginating would be more annoying.
The argument I use is how often to people need to go back more than 2 or 3 pages? If it's not often, why not just show them those records on one page. If it is more often, I'd argue pagination likely isn't helping much anyways. At that point, perhaps a search or filtering option would make more sense.
I both like and dislike Google's pageless images search. I find it very useful that I can just scroll and see the images, and that I can very quickly compare two images that might normally be pages apart. Pagination would require me to constantly flick between tabs in my browser.
I don't like it because it seems to chew up a boatload of bandwidth, something that the company where I work is trying to conserve (three cheers for expensive bandwidth costs!)
