iPhone & Mobile Web: Pagination vs. Load more vs. Scrolling

Question

We're working on a iPhone app and mobile website with search results loaded from the web. Several sorting options are available, every result has a photo. There are potentially hundreds of results.

I see 4 patterns to navigate the list:

1. Load everything, don't use any kind of pagination, just scroll down. Thoughts: Too much data has to be loaded (bad for speed and the user's data plan).

2. Load a certain number of results, lets say 20, and use classic pagination ("next page" and "previous page" buttons). Thoughts: Con: The user has to click back instead of just scrolling up if he wants to go back to the first page. Pro: Every page has a real URL (SEO relevant). My preferred version for the mobile web solution.

3. Load 20 elements, put a "load 20 more" button at end of the list (used in App Store by Apple). Thoughts: Quite elegant for apps - but why use it if you can load the results automatically? (see 4)

4. Load 20 elements at start, load the next 20 when the user reaches the end of the list. Thoughts: My favorite pattern for the app, could even be used for mobile websites if SEO is handled properly.

Questions: Are there any other things to consider? Do you agree with my thoughts? Why doesn't everybody use pattern 4? (not even Apple)

Related questions:

• In what situations would pagination be perferable over scrolling on the iPhone?

• Is scrolling better than clicking to reveal more content?

Answer 1

Approach #4 is especially useful on the iPhone, where you can scroll all the way through a list with just a few swipes of the finger. Having to manually click through pages of results breaks up that flow. I'd do it this way — Apple isn't always perfect. ;)

As far as SEO optimization, you could still keep your separate URLs on the back-end; you'd simply request them automatically as the view is scrolled (eg, /results/1, /results/2, etc..).

Edit: this fantastic, older answer appears to cover the issue in more depth.

Answer 2

It's a balance issue. Some thoughts:

• In case #1, you put up with a delayed load up front in return for a smooth experience later. Depending on your app's use case, that could be preferential (imagine reading twitter and having to wait for a load every time you reach the 20th tweet).

• For case #2, every page doesn't necessarily have a real SEO URL since the data could change. Most design conventions for paginated search tell Google not to follow pagination links because indexing individual search results pages isn't very valuable to searchers, and like I said, the data could change.

• For case #3, this works well for situations like Google Images where you load a bunch up front, but you don't want to load too many because maybe the use case dictates that 80% of your users are satisfied with the first page. But you do want the user to be able to request more when they want, so you have a "load more" button.

• And as far as #4 is concerned, the reason why you don't see this more often is because most apps are fine with #1. Loading new items every X results creates a stop-start experience which often isn't preferential if you're going for a quick scan scenario (and if you're not, then maybe this kind of list isn't the right control for you).

When confronted with decisions like these, I tend to take a step back and reconsider the design. Sometimes that's not possible - for instance, like mentioned above, Twitter is by its very nature a list, and you can't load all tweets since the beginning of time, so the user is going to have to put up with loads here and there. But fortunately tweets are very light, so you can load quite a few of them before you have to snip. For other data, say, search results on a travel site where you have photos for each result, I might consider a different design approach.

Answer 3

A key problem with 4 is when the illusion that they have all been loaded breaks down. A fast flick and suddenly you have to show a placeholder for the not-yet-loaded image.

Why doesn't everyone use pattern 4? I think it's because for the users who forge ahead a gallery of same-sized placeholder-images is unnavigable. You've no idea where you are. Not a problem with explicit loading of 20 at a time. It slows your user down enough. Developers don't use pattern 4 because there is work to do to make the entries with placeholders look good, even without their images, and to be navigable too - and that is hard to do well.

A suggestion to solve that for 4

Find a way to load an approximation to the dominant colors of the images almost instantly. Far less data. Then in the app you can construct custom placeholders using those colors with text that says what the images are. This will be navigable and remain so when the images arrive. There will be less of a jump-discontinuity in the visual appearance when they do.