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:

3 Answers 3


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.

  • Thanks for your answer and the link (I've read this answer before I asked the questions, it's great but it doesn't really cover mobile).
    – Phil
    Commented May 18, 2011 at 20:44
  • +1 for endless scrolling. The best implementation I've seen is Facebook on both the web version and the iPhone application.
    – djlumley
    Commented May 18, 2011 at 23:13
  • If the data is trivial (text, small thumbnails), auto loading is the most efficient for the user. Commented May 19, 2011 at 0:28
  • @djlumley Facebook's is pretty addictive. You tell yourself that you'll only read a page's worth...and the end never comes...
    – Phil Cohen
    Commented May 19, 2011 at 0:34
  • +1 for the excellent link, which is great because it points out that pagination is only effective when it's used for semantically different groupings, while pagination to avoid scrolling is always arbitrary.
    – Justin
    Commented Apr 9, 2016 at 18:10

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.

  • Thanks a lot for your detailed answer, very helpful. Reconsidering the design: It's a classified search and there are alternative views (gallery etc.), an advanced search and several sorting option. The user has the choice: Enter more data to get more precise results or browse a longer list. The result list with picture and some key data is the main view and people use it a lot - sometimes without a real goal but just for the fun of browsing the objects (it's the 3rd generation of the app). Hope that helps to clarify.
    – Phil
    Commented May 18, 2011 at 20:54

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.

  • Sorry, I think I wasn't clear enough: #4 would work exactly the same as #3 but the loading of the next 20 elements is triggered automatically as soon as the end of the list is reached (it would say something like "loading 20 more...")
    – Phil
    Commented May 18, 2011 at 20:58
  • Ah, OK, then mine is actually method 5 :-) "Creating an illusion that they have all being pre-loaded". Is it a contender for your actual needs? Commented May 18, 2011 at 21:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.