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:
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).
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.
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)
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:
Answer
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.
No comments:
Post a Comment