Alternatives to pagination?

Question

With Google Appengine, we can page to next page of a query using a cursor and with some effort we can also go to the previous page. But there is no good way to go to the n-th page, I believe for scalability reasons. It can be possible to implement "last" page if we do a reverse query and we might be able to go to the n-th page but I'm not sure whether it will work since I never saw an example of it, but according to the manual it's supposed to be doable to iterate to the page you want:

So if I can't implement a complete pagination I'm thinking about doing it in alternative ways:

1) Infinite scroll e.g. like Facebook displays status updates. There are no "pages", only scroll.

2) Just a button on the bottom which says "show more". I've seen sites that use this for their product catalogues and it was ok.

What are the drawbacks of chosing either of the above as an alternative to "classic" paging (First Previuos Next 1 2 3 4 .... 17 18 29 20 Last)

Spec my case involves listing articles by time (newest first), 50 articles per page in an app similar to craigslist listing classified ads. So there could be workarounds that I can use for my specific problem since I list articles according to time and I can page to the next page using cursors, but that's also all I can do and I'd like to deliver a more complete solution.

References:

https://stackoverflow.com/questions/18697058/google-app-engine-search-api-set-cursor-at-a-specific-position

https://developers.google.com/appengine/docs/python/ndb/queries#cursors

Answer 1

Questions I aks myself when choosing the right pagination solution:

1. Will users be addressing a particular page? If no - then don't do numbers, just prev/next or infinite scroll.
2. How often items will be published to the feed. If often, then if I give page number to somebody it will become not correct in an hour - he/she will not found the item on that page. It's twitter's case. And they don't use numbers. They use infinite scroll.
3. Is an item actual/needed only for some short period of time (hours, days)? if yes - then no need in page numbers. Facebook's scenario - infinite scroll.
4. Does user look through many items before choosing the right one? If yes - then page numbers are needed. Google's case.
5. Do you need to show that you have many items to convince users you're cool - then use page numbers.

Answer 2

Unless there are performance issues, let the user chose between pagination, infinite scroll, filtering and sorting of content. One way to think of it is letting the server decide what to deliver depending on load. At high traffic only 10 items will be delivered on each request delivered by Pagination/infinite scroll and allow for filtering. It would be sort of a “Responsive Server” instead of trying to do everything on the client side in static fashion.

The drawbacks is that the designer decide how content is being delivered, without letting the user chose from a set of options. Personally, I think both methods are bad UX, since it doesn’t allow for inline search. Users who consume large content would like the ability to search within the page - which is not possible if you paginate long content. I've seen user hitting ctrl + F and then started typing to find exactly what they need - faster. Having pagination or infinite scroll makes this process much harder.

Answer 3

well, this is a tricky one, because:

• numbering pages doesn't give the user any information other than the percentage (if he makes a calculation) of how many items he has seen and how many more not viewed items remaining. ANYTHING is better than those numbers.

• on the other hand, this kind of items pagination is immensely popular. EVERYBODY knows what it does and how to use it.

Drawback of the "infinite scroll" and "load more" is that the user has absolutely no idea how many more items are there. Signposting is a very important UX principle.