Coding Horror: The End of Pagination
codinghorror.com
codinghorror.com
I loathe infinite scroll. It puts you at the mercy of the site doing browser caching right (no one does) otherwise you click on a link, click back and then have to start from the beginning again.
Even Apple gets this wrong (you'll reach a point going through the Top Charts in the App Store where pressing Back reduces you back to the first 10 results).
Pages can be bookmarked easily, which can be incredibly important. Paging is also easier for crawling (otherwise it requires some JS evaluation or other hackery).
DZone is a good example of a site that annoys the crap out of me with infinite scroll.
Seriously, cut that shit out.
Drives me fucking insane.
I share exactly the same feelings. Want to create a Facebook page: http://i.imgur.com/vZ5LD.png good luck! It's like the game where you have to click a button but whenever you hover over the button it moves.
My preferred solution to pagination: by default, load a large number of results per page. The markup overhead is minimal with gzip, database hits can be mitigated with caching, and images can be lazy-loaded if necessary. Best of both worlds, and friendlier to users and search engines alike.
Also, there's no reason pagination can't work inline (ie, link to "Load 10 More Results"), which also gives you the best of both.
But the argument that your "page 867" means nothing remains.
What's the solution? I'm not sure and it probably depends on the application involved.
One idea in search might be to return fifty items and give ten suggested refinements by key word or otherwise.
Pages can be bookmarked easily only sometimes! Everybody seems to have adopted the same database-centric but user-hostile (and cache/crawler-hostile) approach to pagination of posts (see: any blog platform, engadget, tumblr, etc).
Their brain damaged flow goes: You make a new post. The new post appears at the top of the front page. But, the front page has a limited number of story slots. So, the oldest story on the front page gets pushed to page two. But page two has limited slots, so the oldest story on page two goes to page three. Repeat for every page. Some sites have tens to hundreds of thousands of "pages." (Preemptive note to future comment haters: I know the site doesn't "push" articles to every page because it's all just database queries, but the effect is the same.)
Every time you make a new post, you invalidate all thousand (ten thousand? 100k? million?) older pages. It's absolutely moronic. Google has no chance of keeping up. You make one new post and Google has to re-index thousands of pages.
The proper solution is to make pages "fill up" then have your root page point to the highest numbered page. Example: http://omgpagination.tumblr.com/ would logically be page 600, then the "Older Posts" button would link to page 599. Instead, everybody right now makes / always be page 1, "Older Posts" always links to page 2, etc. But those URLs aren't content stable and every update invalidates your cache of the entire site. Your oldest posts on your site should always be on page 1, not a moving target of page {TOTAL_POSTS / POSTS_PER_PAGE}.
In short: be a little more clever and do the right thing for your caches. What's good for your caches is inevitably good for your users too.
Infinite scroll is useful when the time and space is now for the context.
As noted by both parents, implementations for both could be better.
You shouldn't be allowing Google to index /page/2, /page/3, /page/4; that content is obviously going to change, and no user is ever going to search for "page 9 of the archives of example.com."
Moreover, I have to make code, that generates link to my newest page more complex.
Another consideration: it could be beneficial from SEO perspective if content constantly shifts on older pages.
You just link to the root. It's conceptually page 600, but you don't actually have to specify the number. Imagine that the blog is you writing pages sequentially in a book. The oldest content is on page one; the newest content is on the last page. You don't need an explicit number to get to the newest content if you use the convention that an unspecified number means to go to the last page.
Say it had 10 items (full page size). But then 1 new item was posted. Should we create new root page with just 1 item?
Should we ask users to click on pager after viewing just one item in search results?
The other option is to use a "start" parameter which is the offset of the first item to load, and you always load that item + the next 9. However this means you have N cached pages instead of N/10.
So the number of items on the most popular page (root) would fluctuate a lot.
I don't think that would make my users happy.
I don't understand your other option. Are you suggesting not to show 0...9 most recently posted items on the first page?
That would be confusing to users.
Besides, I still see no business advantage of making content hardwired to certain page. If anything, it's better to change page content from SEO perspective.
Makes it more easy to find things you read a few days ago but didn't bother bookmarking and then later you realize you have to find it again. "Hmm, i read about it monday morning"...click click BANG! everything there just the way you remember it.
On most other news sites i can usually not find old articles even after 15 minutes of searching with both google and the internal search.
That would also make viable creating links and bookmarking based on your current position.
Apple gets a lot wrong. Personally, I think their website is horribly difficult to navigate - specifically their web store and web-based app store. The site is chock full of beautiful graphics and plenty of information, but I can't believe how difficult it is to buy the damn thing once I've made up my mind. The call-to-action buttons (ie "BUY THIS RIGHT NOW") are tiny, nearly invisible, or nonexistent. Not what you'd expect from the tech powerhouse that is Apple.
I'd love to do a writeup on this one day. I feel like I'm crazy finding the website so difficult to navigate, but there's no way I'm alone here.
I think it's because if you decide your going to buy a mac then your going to buy a mac and apple get a cut regardless of where you buy it so there's no incentive to have to convert you right that second before you walk out the door.
The entire apple website is basically just computer porn, it's designed to create a lasting emotional impact rather than to feel like a shop.
* The right side contains a scrollbar annotated with years and months, so you can efficiently navigate to posts from a particular period.
* You can deep link to a specific months: https://www.facebook.com/<profile>/timeline/2008/11
* The center line visualizes that the feed continues and that the user can keep scrolling (until they reach their birth)
* Displays a loading bar while new posts are fetched
* No footer and a static header.
Two problems:
* Forward/backward buttons doesn't work unfortunately.
* Webspiders does not make sense for such a closed system, so I'm not sure how they would be able to index such a site.
--- I would really love if other sites would adapt to this scheme of numbering pages by their year and month. Try navigating through which commits where introduced a year ago in a Github repository: https://github.com/mirrors/linux-2.6/commits/master - it ends in a binary search through page numbers! (You could use the CLI, but that is not the point here. Say you need to link to a particular line in an old commit)
Google thinks pagnation is important else why would they produce and suport the new rel tags prev and next.
That's one to many.
It doesn't matter that they reflect different things - client-side display of already-retrieved content and interaction with a server for new content. That's a detail that a user of software should not have to react to.
Infinite scroll is one response, maybe there are others?
My browser handles correctly what you just described while browsing huge pages, except may be the bookmarks. Or may be we simply visit different sites, I love to read books and wikis online.
I won't say that you change your browser, as that path leads to endless religious wars, but bear in mind that there's people like me with the exact opposite mindset to yours.
I feel your pain. So I came up with a hybrid pagination + infinite scroll solution last year. I can't implement it myself but I'd love to see someone try it.
Basically it puts in pagination links in between the content loads so you can easily skip ahead or go far back without having to scroll your fingers off.
I definitely have an axe to grind because it breaks my code, but I really believe it's very bad for discussions. In particular the case of only a single comment and it's children appearing on the first page of comments on threads with large number of comments is the biggest problem. It leads to only one response to the article being heard and has the side effect of greatly encouraging piggy-backing on the "first post", as it were.
edit: when I say 'my code' I mean my code that's forked from wvl's hckrnews.com extension and any other extension that highlights new posts since you last opened the discussion.
This browser window may be sitting in the background for hours if I'm busy, and by the time I get to read it, reach the end and press "More" I'm presented with "unknown or expired link" which, to me, is the culmination of disrespect for the reader.
If I am 3 pages deep in a thread and press the "More" button then if I have been on the page for a certain amount of time I get the dreaded "unknown or expired link" and have to click back to the start and through a load more pages.
I mostly agree with wumpus here as this relates to search results, but it is interesting that forums are brought into it because forums (generally the smaller, community type forums with long-tail discussions as opposed to reddit or even HN where discussions are generally about 24 hours max and then dropped) are the one place I absolutely love pagination.
The unfolding discussion of a particular thread tends to have a timeline in my brain that maps to the pagination of the thread. eg. Oh, subtopic XYZ, that first came up at about page 5... lemme jump over there and refresh my mind on how that came up.
Taking away pagination in forums would be a net negative for me, much like code folding is a net negative for me (I tend to have a map of the code in my mind that is impossible to keep if the code is folded in some random configuration).
Granted, this is subjective and entirely personal, so I'm not saying he's wrong (or that code folding is wrong for everyone), just that getting rid of pagination is not necessarily great for all people in all situations.
Perhaps it would work better if the code were simply hidden instead of collapsed. Then the non-folded code would remain in the same place as before, and it would be less disorienting.
Maybe there is a need for a support group here.
http://notepad-plus-plus.org/assets/images/docMap2.png (on the right hand side)
To do a search on most phpBB or similar forums you have to first be a registered member, fill out a big complicated form and often solve a captcha.
Part of the reason for this I guess is that many of these forums are hosted cheaply so the IO/CPU overhead for doing many searches is not trivial.
I can't count the number of times I've been on the forum and someone has asked a question and they get directed to the search feature.
I also like the feature some forums have where you can show the entire thread on one big page if you so choose.
Facebook does this right now and it seriously pisses me off. Though in Facebook's case they do eventually stop loading more updates so I can click on something in the footer, but other sites definitely don't.
Please don't do this.
Pagination is also friction."
Actually if you're surfing on a flaky internet connection, endless pagination has MORE friction. With pagination you can click on the "next" button again if it doesn't load the first time.
If the javascript doesn't want to fire off another request in the endless pagination series and the last one didn't work, you're just screwed.
This makes facebook especially, incredibly annoying to use on flaky wifi.
Endless pagination only makes sense if you consider content after ~4-5 pages to be near worthless and don't intend for people ever to read it.
Curious how much havoc that would wreck on the scrollbar & swipe scrolling on mobile.
In the end we had to replace the endless bit with a big "load more" button though, for unrelated reasons.
I think the analogy of the forum posts are bad as well where people don't read the previous 4 pages, I think the issue more with forums is that there is a large thread to follow and it generally has to be followed from the beginning. You have generally landed on page 20 of a forum post because it has an answer to a query you put into a search engine. You don't land on page 20 from the forum itself!
In this I am a firm believer that if it ain't broke, don't try to fix it. Why should I as a developer over think about maintaining page position when clicking the back button or showing different paginated content to search engines for indexing? I don't feel like I am putting a lot on the user and I always know where I am with paginated content.
For example: "Look at the blue shirt on page 5" rather than "Look at the blue shirt visible after about 30 seconds of scrolling down"
Also, when the page is reloaded, I have to scroll all the way down to where I was (which may take longer than I want it to because the page needs to load everything before my target).
Not everything is search. Sometimes you genuinely want to see the list. eg. transactions in your bank account, messages in your inbox, posts on your Facebook wall, etc.
Even if you were only searching for one item (say you're searching Google for an article you read a few weeks ago), sometimes alternate results are useful too. What's wrong with discovering something new?
I really like the idea of intelligent search and only showing relevant content vs just showing everything on the page and hoping people will find it. It seems so obvious now, but the status quo is so ingrained in us. Sometimes I do want to see the 873rd image, sometimes it's just the one I'm looking for, but burried under endless pages of other images. Having some sort of search (either tagging, date, or text) can really make this process easier for users.
That's just the opposite extreme of thousands of paginations.
I, personally, don't search that way. I generally look for a few good results, and then draw my conclusions based on the total of what I read. Rarely do I look for the page that has the answer. Maybe because I'm not looking for answers.
The problem comes in when someone is looking for that one comic they saw a few years ago. Unlike xkcd, this comic hasn't implemented full-text search yet, so if they can't do a manual comparison sort, they have to go over every comic. What's a natural way to do this?
Still new to web development and user interface design in general; this is probably a different problem altogether.
If it is too much of a pain to manually transcribe the text, perhaps using OCR?
Usually when I remember a comic and am trying to find it, I remember one specific detail, whether it's a picture or text.
tl;dr Nice thoughts about new ways to interact with web data with a needlessly sensational, counter-productive title.
If there are too many results, what I want is some way of filtering out the results that are obviously not relevant (because not in the correct language, or too old, or too recent, etc.), not the ability to "scroll" forever (infinite scrolling adds DOM elements to the page to the point where the page is so big, nothing works properly anymore).
Associated HN discussion: http://news.ycombinator.com/item?id=2592741
Of course, the other major split from Atwood is that I think he's dead wrong. It's not about delivering better targetted results. That will, inevitably, fail. It's about the other part he briefly mentions- reducing irrelevant friction. The reason Google suceeded only with shorter results was because the friction of scanning through and filtering a result was so very high (taking a couple excerpts, a title, furrowing one's brow, thinking hard, and making a binary click/ don't click value-judgement guess).
https://chrome.google.com/webstore/detail/mmgagnmbebdebebbcl... https://addons.mozilla.org/en-US/firefox/addon/autopager/
It's great.
But I'm looking for a list of similar items in order to compare them. Many -- if not most -- times I perform a search I have but a vague idea of what I want. I throw something at the engine, take a look at the results, then decide whether to restate my search or not. A list is a perfectly good answer to many questions.
And this business about pagination? I'm sorry Jeff, but infinite scroll must die. It's a god-awful user interface mess. If you like this sort of thing, why have pages at all? The web should be just a seamless, flowing experience without any context-switching.
I almost feel like we are purposelly being baited by Atwood. (Bloggers? Purposely stirring up trouble for pageviews? Say it ain't so) It kills the entire concept of a page. It destroys the user's ability to know how much of something they are seeing, and makes linking a disaster.
Make it go away.
For example, in google image search, "back" returns to the head of the list, even if you were on page 20. E.g.:
Sometimes when you click back, the "Page" of results you clicked from is omitted from the scroll. (result numbers jump from 50 -> 101 for example).
What's even more frustrating than losing your place is your place not actually existing anymore when you click back. I've grown to look at the result number before I click, so that I can try and find it quicker when I return.
For me Facebook works pretty well. I like to keep quickly scrolling down (using trackpad inertial scrolling) until I've skimmed over everything new in the feed. Forcing me to move and pinpoint the cursor to click a "Next page" link would certainly add friction to that.
Google's search results, OTOH, are a completely different use case, where you want to have full control to the paginated browsing, constantly navigating back and forth.
Perhaps this involves a distinction between "lean back" and "lean forward" use cases. Leaning back, it's nice to just keep on scrolling with simple finger swipes.
Some hybrid scheme may be more acceptable in which the page folds segments that you have scrolled a certain distance past, and unfolds a segment that you are entering. A Floating nav helper could display which segment/page you are currently on and perhaps even provide the ability to jump a previous/next or x segment. Best of both worlds™ navigation
1. If I want to find a particular item within the first "page" of results, but I've scrolled down 10 pages of results, find that item becomes pretty tricky!
2. Let's say I have a user who scrolls down 1000 pages. What does this to the browser? I'd imagine it grinds to a halt...
The only solution would be to have a load page for the previous results. Here again, the issue I highlighted in point 1 becomes more emphasized. Especially if the search results change while it reloads (though you might keep the results for the user's session - but this sounds like a scaling issue).