A coworker recently asked if anyone in our org had a ‘pattern’ for the display of a pagination control for mobile. My head started swelling with my usual “that’s the way we’ve always done it” rage. (You can search the web for that phrase plus the word ‘monkey’ for a great story.) As I recall being told, Steve Jobs got a standing ovation at the annual Apple dev shindig when he made it super easy for mobile developers to point a table control at a data source and have iOS load and scroll the table. It wasn’t especially dealing with the challenge of super long lists, or slow retrieval times… just making list-serving easy. And the iOS/Cocoa framework handled the ‘pagination’ matter: don’t paginate (all caps), just show the list, and use the most natural gesture in the world to pan it vertically, a sweep of the finger. That was the pagination: your finger.
And 13 years later, along comes a new bunch of thing makers and says to themselves, how can we complicate something simple by using a paradigm that itself started for only poor reasons, misapplied, and now use it for more evil? Pagination, at least with the advent of the web, started because of a combination of a mistake and a problem: 1) the mistake that an incredible amount of (unstructured) result items is a good thing, and 2) the problem of 1200-baud modems loading even a screenful of information much slower than human scanning speed. Do any of you still use ‘dial-up’ and 1200-baud modems? Maybe you work in a business that still has a fax machine 
. If so you might be able to hear it make the scratchy dial-up ‘carrier’ signal sound of a modem; fun.
I love this thread because it is so demonstrative of all things web… and usability. I counted in it …
- 6 genuine user-oriented ‘use cases’;
- 3 of what I call ‘vendor values’ (or internal use cases) such as SEO page hits and advertising;
- and a smattering of pain points (such as no ‘moral compass’ of a scroll bar).
The answer to all usability/ux questions is ‘it depends,’ and a few comments have started with that. There will be no single debate winner to 12 functional requirements.
The pieces of the diagnosis and remedy are strewn throughout the comments. I am not adding much beyond organization and a bit of my own bias: Google gets away with presenting its results as it does (with relatively poor precision tools) precisely because its milieu is one of unstructured data, and because it can substitute crowd sourced intelligence for user controlled tools. In response, the rest of us has gotten convinced that if our queries return 10,000 results, we must display 10,000 results. Are there uses cases where all 10,000 are useful; yes, they are called edge cases. We have all occasionally had them. But our solution is not ‘pagination’ but tools possessing power commensurate to such use cases: faceted or parametric search, and fully sortable tables. (I once loved using a Google alternative called Copernic that presented web results in a table, where I could sort on at least URL, which immediately enables scanning past frivolous sites). A world-leading medical site limits its result set to 3 ‘pages’ or so I’ve been told. Sounds smart to me.
The choice is not between pagination and infinite scroll. It is between static pages and infinite scroll. And within either, the first choice is how many results are sensible for your primary use case: for search, it’s good answers or relevant information. For blog comments and other ‘reading-like’ things, it’s totally different… it depends; infinite scroll might be right. And if your list is long enough that it somehow requires being many, many pages/scrolls, then your use cases should guide you to whether you need precision tools to serve your users. As one commented, “The rest becomes exponentially unimportant.”