programming and human factors
by Jeff Atwood
What do you do when you have a lot of things to display to the user, far more than can possibly fit on the screen? Paginate, naturally.
There are plenty of other real world examples in this 2007 article, but I wouldn't bother. If you've seen one pagination scheme, you've seen them all. The state of art in pagination hasn't exactly changed much – or at all, really – in the last 5 years.
I can understand paginating when you have 10, 50, 100, maybe even a few hundred items. But once you have thousands of items to paginate, who the heck is visiting page 964 of 3810? What's the point of paginating so much information when there's a hard practical limit on how many items a human being can view and process in any reasonable amount of time?
Once you have thousands of items, you don't have a pagination problem. You have a search and filtering problem. Why are we presenting hundreds or thousands of items to the user? What does that achieve? In a perfect world, every search would result in a page with a single item: exactly the thing you were looking for.
But perhaps you don't know exactly what you're looking for: maybe you want a variety of viewpoints and resources, or to compare a number of similar items. Fair enough. I have a difficult time imagining any scenario where presenting a hundred or so items wouldn't meet that goal. Even so, the items would naturally be presented in some logical order so the most suitable items are near the top.
Once we've chosen a suitable order and a subset of relevant items … do we really need pagination at all? What if we did some kind of endless pagination scheme, where we loaded more items into the view dynamically as the user reaches the bottom? Like so:
It isn't just oddball disemvowelled companies, either. Twitter's timeline and Google's image search use a similar endless pagination approach. Either the page loads more items automatically when you scroll down to the bottom, or there's an explicit "show more results" button.
Pagination is also friction. Ever been on a forum where you wished like hell the other people responding to the thread had read all four pages of it before typing their response? Well, maybe some of them would have if the next page buttons weren't so impossibly small, or better yet, not there at all because pagination was automatic and seamless. We should be actively removing friction where we want users to do more of something.
I'm not necessarily proposing that all traditional pagination be replaced with endless pagination. But we, as software developers, should avoid mindlessly generating a list of thousands upon thousands of possible items and paginating it as a lazy one-size-fits-all solution. This puts all the burden on the user to make sense of the items. Remember, we invented computers to make the user's life easier, not more difficult.
Once you've done that, there's a balance to be struck, as Google's research tells us:
User testing has taught us that searchers much prefer the view-all, single-page version of content over a component page containing only a portion of the same information with arbitrary page breaks.
Interestingly, the cases when users didn’t prefer the view-all page were correlated with high latency (e.g., when the view-all page took a while to load, say, because it contained many images). This makes sense because we know users are less satisfied with slow results. So while a view-all page is commonly desired, as a webmaster it’s important to balance this preference with the page’s load time and overall user experience.
Traditional pagination is not particularly user friendly, but endless pagination isn't without its own faults and pitfalls, either:
pushState.
For further reading, there's some excellent Q&A on the topic of pagination at ux.stackexchange.
Above all else, you should strive to make pagination irrelevant because the user never has to look at more than a few items to find what they need. That's why I suspect Google hasn't done much with this technique in their core search result pages; if they aren't providing great results on page 1, it doesn't really matter what kind of pagination they use because they're not going to be in business much longer. Take that lesson to heart: you should be worried most of all about presenting a relevant list of items to the user in a sensible order. Once you've got that licked, then and only then should you think about your pagination scheme.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
On mobile devices the experience is often better if you keep pagination and get rid of scrolling instead.
Peter Venable on March 27, 2012 4:09 PMI don't know about that; Twitter's mobile client does endless pagination on mobile, just like the desktop web UI. Remember there's still a "page size", it just depends how much you need to scroll down to trigger the next load.
Jeff Atwood on March 27, 2012 4:15 PMPagination has one really helpful power that endless scrolling lacks: the ability to quickly jump to the end of the list, or (sometimes) the middle, etc. Not every application requires this, but I sometimes find endless scrolling to be truly irritating when I know I need to go deeply into the information and so end up scrolling... well, almost endlessly.
Matthew Frederick on March 27, 2012 4:27 PMI'm going to speculate.
A lot of pagination of this sort dates back to when companies like Google had to distinguish themselves with the sheer mass of available data they could flaunt and their skill at having a huge field of sites to choose from when a user typed in terms. You'd type in a search term like "Dog" at a time when other search engines and sites might offer you 800 or even 2,000 matches to your query, Google could say "Oh, that's 150,000 matches here.... want to check?"
If you spend any time looking down those goat paths, and regardless of your theory, I've had to spend time doing just that, leafing through hundreds and hundreds of search matches looking for variations or possibilities, then you'll find they actually collapse. They're often not really there, not actually present, but just showing you what you COULD get. They almost always require refinement. So either the whole thing is better (people who want to paginate like that exist, me for example) or it's worse (it's actually a lie, nobody is going to give you all you can eat if you try to eat everything).
Jason Scott on March 27, 2012 4:31 PMYour article talks mainly about pagination of search results, but that's only one use case where many 'items' need to be shown to the user. Facebook and Twitter (as mentioned) use this, and it's certainly not a searching/filtering issue -- that's just the data requested by the user.
Facebook I think have a very good approach by giving semantic meaning to their "pages" on the user timeline: you jump to "2009", rather than "page 5". Certainly, it isn't always as easy to group results meaningfully like this, but when possible it's a very good outcome for the user.
Nick Fisher on March 27, 2012 4:34 PMI'm always surprised when I see a website with really small pagination buttons, especially when its a shop and there are many pages of products that you need to look through. If the customer needs to really concentrate to know there is more than one page of results, it must impact sales massively.
Sbrandwoo on March 27, 2012 4:34 PMi think it depends where you are, if you are in a generic environment like google search you are essentially trying to filter all the stuff they have into things you want to know, you are focussed on your search result. On the other hand you can have large result sets of relevant data. the context is already as you wish. A good example of this is something like netflix or film flex in the uk; you want to watch a film of a specific genre but you don't know which one, there are pages of results and you are happy to click next or page 7 and look at the items that are there. I guess the key here is perception of the target you are searching for. On google you put terms in and expect focussed results, you tailor your search terms, use quotes(") and aim to get the stuff you want. On a film site you may want to watch a comedy - you already have the filtered results but you want to browse these to find something maybe you haven't seen but (in my case) check all the stuff that is available and make sure its the best one there. Ultimately its the perception of finite versus infinite, anything over 100's is probably cognitively treated as infinite (it is with me) but when you already perceive the results are focussed then you may be prepared to venture beyond page 1...
Maffyoot on March 27, 2012 4:45 PMThe ability to jump to a specific point in results matters. For example, searches which let me sort by date, price, etc. Times when I like paginated search results are sorting by date then jumping to something a few years ago, sorting by price then clicking to something in a price range I want and being able to see the high and low end quickly, and being able to quickly click to page 5 of results if I rerun a search and want to go back and find something I know exists.
Being able to jump to a specific point in a list will make perfect sense to anyone who has ever completely opened another person's Facebook wall or Twitter feed in order to see what that person was up to 5 years ago. Then again, maybe they want that to be hard to do and only open to the techy or persistent.
Wilhelmina Randtke on March 27, 2012 4:50 PMI don't know if Picasa still does it, but the Windows Picasa client circa 2005 or so had a scrollbar like control but it stayed anchored in the middle, and when you pulled it down you went downwards, the further down the faster, and vice versa. This saved you the confusion of thinking your scrollbar represented where you were in the list, but added new confusion by co-opting a familiar control for a new purpose... not sure if it was a win, but I kind of liked it myself...
In terms of the scrollbar indicating "how much more is there", I've noted that a lot of less advanced users don't have much comprehension of this. And in the Apple universe at least the scrollbar has gotten demoted significantly (since the start with iOS, now with Lion on OSX), not without controversy (http://www.slate.com/articles/technology/technology/2011/11/computer_scrollbars_why_is_apple_eradicating_a_linchpin_of_user_interface_design_.html)
I implemented endless pagination on http://unicodinator.com (which lets you scroll through Unicode 0000 to EFFF) and it works really, really well. The trickiest bit is to not only add content in the direction the user is scrolling towards quickly enough and far enough ahead that the user can't get ahead of you, but also to remove content in the direction the user is scrolling away from so as to not choke the browser. Luckily with this site the content is fully client side generated and is pretty lightweight. With some other projects that have to load dynamically getting all this timing correct is much more difficult to get perfect. Still, I think it's a really worthwhile technique...
Joelarson4 on March 27, 2012 4:57 PMFYI here is a jQuery plugin for doing endless pagination: https://github.com/fredwu/jquery-endless-scroll
Fredwu on March 27, 2012 5:02 PMI find the endless pagination thing obnoxious on mobile devices. First of all it taxes the browser after several pages, and if you switch applications long enough for the browser to think it needs to reload, you're stuck with the first collection and have to scroll a ton to get back to where you were. I also have a problem with the way some endless pagination techniques work on the desktop as well; Facebook's new way of doing lists is damn near impossible to scroll by grabbing the scroll bar and dragging.
I would like to see a smarter endless pagination where it's not just added to the bottom in an ever-growing page, maybe instead it also pops the last one/set off the top, so you've always got a set number of results visible and you can "scroll" through that, or something similar. Seems like that would make the next/previous sets easily cache-friendly for speed and should still be state-friendly.
Nathan Bank on March 27, 2012 5:03 PMDoesn't pagination also allow new Ads to load with each page? How does this work with endless scrolling?
Jeremy Craven on March 27, 2012 5:06 PMWhat I can't stand is all those article-based sites (such as news sites) that insist on breaking their articles up into bite-size chunks at arbitrary points, when they're really not so long that they can't be put on a single page. Usually the actual text content is just a small part of the page, surrounded by all sorts of wasteful crap that makes each page take too long to load; a well-designed page with the entire article in one page, and less superfluous junk around it, would actually load faster than the individual pages of the broken-up article.
Dan Tobias on March 27, 2012 5:15 PMThat really depends on the type of site. When you go to a shopping website, and sort the results by price, you might want to go to the middle page to see what's available in that range. You can't really do that conveniently with infinite scrolling.
The Configurator . on March 27, 2012 5:29 PM>who the heck is visiting page 964 of 3810?
When I'm looking at all the lolcats or demotivational posters. One of my favorite lolcats doesn't show up in indexing, but you have to search and then click "yes I want to click on this".
http://icanhascheezburger.com/tag/mapquest/
Skip a week of browsing such a fine waste of time, and you can easily end up looking through 30-50 pages of time wasting stuffs.
There are sites I'm not happy with because cut off your browsing at page 20 (such as "overheard in NY" or "overheard in the office").
Tangurena on March 27, 2012 5:31 PMIt's a great idea, and actually slashdot is already doing this on their front page. However, there are some problems:
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).
A Facebook User on March 27, 2012 5:35 PMI agree with Maffyoot:
in many contexts, infinite pagination is actually a hindrance.
Think about a list of 300 items, which I want to review, one by one.
In this case there is no "perfect search term" to use to shrink the list.
My favorite interface let me decide how many items per page I want, say 100, after which I can open the complete list in 3 tabs in the browser.
Having everything in a single page would make the list too long, and besides the problem of server processing resources / network lag, it would make it hard for both me and the browser to scroll up/down with enough speed and precision to any given desired line.
I would also have a hard time remembering the visual whereabouts of a given item in the page (that's quite a problem with infinite scrolling in any context: a line which used to be "close to the bottom of the page" will be "close to the top of the page" after a bit more scrolling).
Otoh having 100 items per page, with many pages open, feels much more natural - just like one would browse, say, a book!
Last thing: all the nice "perks" which make infinite scrolling bearable, like allowing deep linking and spidering, currently cost a lot of development time, and many developers fail to grok the concept properly (or just are not given enough time/money for that), so we see a lot of bad implementations, which give us worse user experiences that we had before.
I still see plenty of sites that only allow a single sorting order in their search results, and have no support for facets/ drill down. Those features are much more useful than infinite scrolling...
Don't forget Duckduckgo's endless scrolling too. So you can get a rough-ish idea of what life would be like if Google actually implemented that.
Pjsdotcat.wordpress.com on March 27, 2012 5:39 PM[quote] Either the page loads more items automatically when you scroll down to the bottom[/quote]
There is an addon that does that. It's called auto patch work and it's one of the most useful addon I ever used.
Hoffmann on March 27, 2012 5:47 PMDidn't searchmash.com do seamless pagination. Or at least load more content when you pressed Space?
Mikel Ward on March 27, 2012 6:16 PMRecently, I've found the endless stream approach particularly bad if dealing with anything chronological. If I want to go to the very beginning of something and I have to scroll through umpteen thousand pages, it becomes a TERRIBLE user experience. If you're going "endless river" you should also give the user to "skip to record 5,678".
Christopher Allen-Poole on March 27, 2012 6:19 PMI think there are other pagination considerations, like ebooks where the 'page' concept looses their meaning, I use to read books in an endless scroll with stanza and felt comfortable with it, while the "new" ebooks apps have implemented the old page schema, even they have page look and feel.
I think all kind of pagination are a technologic restriction that can be (almost) set to "deprecated" in modern interfaces.
A Facebook User on March 27, 2012 6:58 PM"In a perfect world, every search would result in a page with a single item: exactly the thing you were looking for."
I suspect that, early on, Google had the same idea, and the I'm Feeling Lucky button was their attempt at realizing it. Of course, that wasn't quite how things panned out.
Taymon on March 27, 2012 7:13 PMBack in October 2010, I gave a talk[0] on the NOSQL database, Riak. Something I mentioned in my talk is very similar to what you are saying here. Particularly that no one cares to paginate through thousands (or far more) results. Beyond that, I was looking at it from a database systems perspective. Certain distributed, non-transactional, non-relational systems, in certain cases, have difficulties keeping absolute counts of items. My insight is that the larger the result set, the less people care about pagination.
[0]http://www.slideshare.net/siculars/adding-riak-to-your-nosql-bag-of-tricks , slides 30-32
I couldn't agree mroe with Christopher Allen-Poole. Whenever I see this, I often want to get to the "bottom" (or often "first") entry. I can't just press END any more, I have to press it over and over and over again.
If the devs could capture the keypress of the END key and just load ALL the remaining content, that would be great.
Mark Henderson on March 27, 2012 7:16 PMMy company uses a similar method where the total number of items ("Results") are known we output page "placeholders" when a users stops scrolling at one of these placeholders we go and get that page worth of results and replace the pageholder.
We know ahead of time how many results per page and we have a strict size per result so the placeholders have a height set at the same height the results would be (approx).
This fixes the scroll bar issue and only loads up what the user wants to see.
James Khoury on March 27, 2012 7:16 PMSeems like there are a couple 'complaints' about infinite scrolling that really have nothing to do with the actual scrolling function.
1) "What if I want to jump to a specific..."
I use Amazon and NewEgg all the time. When you sort by price, Lowest to Highest, do you actually jump to page 7 to see what "mid range" prices are? No. You use the price range facet on the left to narrow to what you're really after.
The fact that you can't jump to a specific place when doing infinite scrolling means that the designer/developer didn't think about what her users really want. You can have this problem with a paginated interface.
2) "I hate how I can't get to the bottom of the page"
Actually, I hate this about Facebook's news feed too. This isn't a scrolling issue, it's a UX issue. The manual "show more" link is a mitigation but the solution is to not have to force people to go to the bottom of the page to do something useful (ask why would you want to in the first place).
3) "It will lag the browser"
This is more of an implementation issue and is the one thing I wonder about for these "infinite" scrolling solutions. I totally agree if I scrolled for the equivalent of 20 pages, won't my browser eventually grid to a halt with all the memory? I think the solution of popping off results near the top is a good approach, but technically this seems pretty difficult; also what happens to the scroll bar in that case?
4) How do I figure out where I am?
This is context-specific, I feel. If you are sorting alphabetically, you should provide a quick way to jump to specific letters (like a dictionary). If you are sorting by date, a timeline-esque jumper works just as well. If you are sorting by price, a range works well.
I am in the midst of redesigning one of my sites. I want to implement "infinite" scrolling because it is browsing a collection of items I (the user) own. What I am worried about is what do I do with previous results? The last thing I want is to hang the browser. I like the idea of removing previous items, but my worry is how the user can "immediately" jump back to the beginning of the list when you've removed them from the DOM and effectively need to load/request them again. I think a "virtual" scrollbar would work, if done correctly, one that knew the context of its environment (how many items, where you were, an 'index' of the content to jump to specific points). Sorting alphabetically? Pick a letter on the 'scrollbar'. Sorting chronologically? Pick a point in time to jump to. I would be interested in doing a demo of how this would work.
Kamran Ayub on March 27, 2012 8:28 PMWe've made an attempt at solving some of the friction and pain with pagination in forums by having "in line" pagination in our forum. Take for example this forum post which has an unreasonably large 1,510 replies (at the time of writing this):
http://www.mypivots.com/board/topic/3237/-1/day-trading-with-ttt-and-other-tools
In the URL the -1 signifies the "last page." The algorithm shows the first post, a bunch of links to other pages, and then then last 1 to 10 posts depending on how many posts are on the last page.
When a user clicks on a page number then an AJAX call is made which pulls that page into the page you are viewing and splits up the remaining page links.
I agree with Jeff that forums are fundamentally broken, however, I feel that given the traditional pagination model in forums and this one that we've made the web a better place.
Granted that in the example above with a forum topic with 150 pages this is less useful. However, most of the forum topics are between 1 and 3 pages so pulling in the other 2 pages into a single page that you can scroll up and down through makes this much more usable.
MyPivots on March 27, 2012 10:04 PMConcur. Pagination hasn't made sense since Ajax became mainstream and sane people realized that "the page fold" doesn't exist.
This is also a testament to the fact that... [cont'd]
<-Prev [Comment page 1 of 35] Next->
Jon Galloway on March 27, 2012 10:50 PMI'm all in favour of the idea of endless scrolling. You search engine should be smart enough to let get your wanted result on the first 10 items. The rest becomes exponentially unimportant. I see this in all sorts of apps, but at my dayjob I'm developing enterprise solution apps.
What I noticed is that there are no plans or attempts to go to endless scrolling, while this could defenitly be a added value for the user experience.
Do you see this happening in an enterprise environment or perhaps we should just implement the search in an other way?
This post describes how I solved problems with pagination: http://programmerstrouble.blogspot.com/2011/03/design-pattern-pagination-with-useful.html
I added a hovering hint that shows you what exactly is on that page (ie, price from-to if you are currently sorting on the price field).
I posted this on HackerNews once, but it ended up on page 2 so nobody really noticed ;)
Jouke Waleson on March 28, 2012 12:25 AMI agree with everything you're saying except for this part:
In a perfect world, every search would result in a page with a single item: exactly the thing you were looking for.
If I search for "Ethiopian restaurants in my city", ideally I'd see all three restaurants, with photos of the interior, a relevant subsample of the menu items/prices, and some information about the service/quality/reviews.
If I search for "buy car", I would like to see an array of options, like a matrix which guides me through the relevant tradeoffs (car specs, lease terms) and the $ cost of moving around in that tradeoff space.
Even a "perfect" search engine isn't going to know (although it could presume/make assumptions about) what car I'm going to want, when I don't even know yet. Rather than trying to creepily prognosticate about what my answer's going to be, an ideal search engine would just lead me to the next logical question, along with the relevant info to answer it.
Isomorphisms on March 28, 2012 1:53 AMI absolutely hate the dynamic loading design. Ever since slashdot switched to it, I've been using their /archive.pl page.
It's a nice idea in theory, but in practice it doesn't work. I have less friction when using a paginated page, because I always open the next 5 pages as new tabs so that they can load in the background. I can't do this with the dynamic design - I have to wait a second for each page to load. It's also a pain if I just want to skim the results, due to the breaks between pages.
Proposed solutions:
-give the user a means to control either the initial number/proportion of items loaded, so that someone who is going to read the entire thing can just set it to 100% and have it load for them
-Actually have the pages load seamlessly by caching them beforehand. The browser shouldn't wait until you reach the bottom of the page to start downloading the next one; it should start the moment the first page is done, and download the 3rd the moment it starts to display the 2nd page.
Or better yet, download the first 10 pages with the first, but don't display them until the user scrolls to them.
There are two problems here: downloading all that data takes a while, and displaying all that data makes it unmanageable. Trying to deal with both at the same time only confuses the issue and neglects part of it.
Sometimes, the are no "relevant" items in a search, but the whole set of items is the only relevant unit. For example, in a lexicon or dictionary search, you may want to get a list of, say, all the words that start with "da" and end in "n" shorter than 10 characters, something like:
"lemma:da*n length:[* TO 10]"
When every item of a result set is relevant, what kind of pagination would you use?
Gabriel Rodríguez Alberich on March 28, 2012 2:48 AMI think Alex Micek's progressively-enhanced infinite scroll is the most impressive - doesn't break the back button: http://tumbledry.org/2011/05/12/screw_hashbangs_building
Duncan Smart on March 28, 2012 3:43 AM> Endless pagination should not break deep linking.
I'm glad you mentioned this. I'd take badly implemented traditional pagination over badly implemented infinite scrolling any time.
For the worst of both worlds, take a look at Microsoft Connect. It combines traditional pagination with the dynamic-loading approach normally found in infinite scrolling implementations. Content is broken up into pages, yet the back/forward/refresh buttons are non-functional (and don't even think about trying to open results pages in different tabs - all the links are JavaScript).
Quppa on March 28, 2012 4:04 AMThe only people who don't like endless scrolling is the marketing people, because you get less pageviews.
Dofs on March 28, 2012 4:10 AMEndless scrolling strains browser resources, and when the browser finally crashes and releases its memory, it has no record of the position you were in. Pagination doesn't cost much on the server side (unless you try to keep an accurate count at all times, but that's rarely important). Pushing the work to the client may be seductive because it's the newer technique, but it doesn't even provide increased responsiveness because web developers tend to completely disregard the costs of client-side inefficiency (particularly for memory, which sees a sort of tragedy of the commons).
Lo on March 28, 2012 4:20 AMWith such endless pagination one could also provide a better real-time filtering.
By letting the user hide/remove those results that don't have nothing to do with he's search similar non-relevant results can be let fade away while scrolling. (And an half-second transition would let the user the ability to check that such fading results weren't really helpful.)
Riccardopoggi.wordpress.com on March 28, 2012 4:50 AMWhen the dataset to be displayed is something unsortable "like default search results of Google", I strongly agree with endless scrolling (actually, had created a tutorial about it few years ago: http://www.webresourcesdepot.com/load-content-while-scrolling-with-jquery/ , simply I'm a fan of it).
But, if the dataset is something more like a list whose fields can be sorted (like a list of users, cars with their models-milage-seller's city, etc), than pagination makes more sense as you can guess what may be listed in page 964.
It even gets better if hovering a page number in a pagination informs you about the records in that page (hovering page 968 can say: "Netherlands-Nigeria" if the records are listed by country) so you paginate without guessing.
Umut Muhaddisoglu on March 28, 2012 5:26 AMThey(Google) are doing some experiments with pagination in the gmail blog. http://gmailblog.blogspot.com.br/
Nothing great, but is already something.
Alfredo Cavalcanti Segundo on March 28, 2012 6:33 AMI can see both sides to this. On one hand, I really do enjoy the experience of endless pagination (especially on mobile devices). There are edge cases I can see for having pagination in some form. A random example of one of those edge cases would be something like a list of Royal Navy Ships throughout history. In that case, as a user, I would prefer to be able to jump to a specific page (by letter of the alphabet, not numbers) to find the one I'm looking for. However with the same use case, if I were just browsing the list, I would prefer endless pagination.
This brings up an interesting thought. In writing this comment I would say that both are still a fit, it just depends on the users' intention. I wonder what would be a good UX to solve this? Providing endless by default, with an option to jump to a page? Thought provoking.
Alexander Kahoun on March 28, 2012 7:38 AMPorn searches are the one gaping hole, so to speak, in your argument. In that case, I definitely don't want a limited result set.
A Facebook User on March 28, 2012 9:56 AMThe stupid tiny 'next page' buttons in so many forum designs is one of the main things that make my own forum software with nice big easy-to-click buttons:
http://caerphoto.com/misc/forj_pagination.png
I used buttons because as some have said, auto-loading stuff can be a bit annoying, and feels like you're not really in control of the app/page.
Regarding an earlier commenter's point about overloading on HTML elements, I don't think removing elements from the front of the queue would be a particularly arduous task, and browsers are pretty good at handling large numbers of elements, though obviously it depends on the complexity and content of each new 'page' of items – for a forum consisting of mostly plain text, I would guess a user would get bored long before putting any significant strain on the rendering.
Andy Farrell on March 28, 2012 10:05 AMI actually use pagination some times to click on a page and then "Ctrl-F" and search within that page. aka search within search.
I have even done this with google at times. Often times its for strange meta-data that is not clear how you would get the search engine to bring it up.
Ctrl-F does not work with infinite scrolling however I'm kind of a weird user.
Adam Gent on March 28, 2012 2:50 PMHere's the thing - I really dislike the "No Pagination" thing. Why? Because sometimes I need to send a person to a set of search results rather than a single link - but I would also like to say "It's the third one down on page 3" rather than "Scroll down a few pages and it ought to be in there somewhere".
Timothy Collins on March 28, 2012 2:57 PMI agree with everything Kamran Ayub said and think the idea of having small menus based on context (year/month/price/whatever) is a great solution to the 'where am I' and 'how do I get to page 2000'. The prime example for me right now is with Google Groups. They changed to endless scrolling in their test product and it is now impossible to get back to early 90s posts in busy newsgroups. It renders the archive practically useless. Still scrolling without broken up pagination is great, just need that extra navigation and permalink feature in there.
Deepsomber on March 28, 2012 6:55 PMI think this is a clear example of "I know what is best for you". This kind of no-pagination is really nice if you are looking for some very specific context and easily breaks down when doing anything else.
Example: Sometimes I look for some tweet that I saw in my timeline a while ago. Can't use search (that sucks btw) because I don't know the specifics of the tweet but I know that I'll recognize it when I see it. So I scroll, and scroll, and scroll.. until I get bored with the extremely long page (if only i could skip the first hour and jump directly to the page 10?), or even worst, some problem happens and I have to start over again.
Also, like @Timothy Collins said, good look when trying to send the link to someone: it just doesn't work.
Some comments say that if no-pagination doesn't work is because everything else is badly implemented. Well, pagination might not be perfect but it damn sure helped to circumvent those problems way better than the infinite scrolling gimmick.
José Sá on March 29, 2012 1:39 AMFor the record you should say "Bing's image search". Google implemented their version quite a while after Bing had it in place.
Mike Henken on March 29, 2012 6:10 AM@sbrandwoo: Exactly the opposite.
The focus needs to go to the people who come to buy things, not the people who come to window shop.
Big buy buttons and good reviews, not the chance to use up bandwidth flicking around results.
twitter.com/deworde on March 29, 2012 8:07 AM@Isomorphisms: Actually, what you're looking for there is not 3 pages, but one pages that compares all 3 restaurants, like a reliable review site.
twitter.com/deworde on March 29, 2012 8:09 AMFully agree on the friction argument. I'd like to throw in another element of friction that is loosely related to pagination: the "more" link. And with that I mean a paragraph of text that is trunked to show x characters, and where "more" needs to be clicked to see the full comment, paragraph, or whatever it is. It can be useful on really large sections of content, but when applied to shorter paragraphs it drives me insane.
By the way, I do not agree that you should continue to feed traditional paginated views as well for the sake of SEO. Pagination is friction for both users and search engines. Instead, as you already suggest, a sitemap without pagination is much preferred imho.
Ferdy Christant on March 29, 2012 1:01 PMWhen I am on mobile net, especially if the connection isn't all that great the infinite pagination can be frustrating on image searches and the like, especially if I want to load something else concurrently too.
In my opinion the best solution isn't doing away with pagination, but rather it should be supported by the browser. If I could visit a new site and I would just have to hit a UI button or a hotkey instead of looking for the (usually small) page controls, that would be awesome. Another addition is, that if the scheme would be supported by the browser, than you could start preloading the content of the other pages (hopefully only the textual) once the current is finished so you could search those pages too with the browser's search feature.
I don't know, this sounds really utopistic and I think it would require W3C implementing a new standard. Maybe in the next decade...
Search on the web may be difficult, but a lot of lists can have a logical grouping. If the scrolling speed is maximized for a certain time interval, the list should shift to scrolling through the grouping. If you are scrolling through a list of 500 contacts, at some point, the letters of the alphabet should appear. This makes jumping to a new "page" more practical. This can be done by dates or numerical value. If my search/filter has too many results, shouldn't there be a way to limit the list further?
Joresik on March 30, 2012 9:46 AMwith Facebook, Twitter and Pinterest effectively all using infinite scroll I have wondered how much that feature alone is a contributor of their engagement in the same way "related videos" were to YouTube in the playing viewport of embedded videos. It's unlikely that Google will defer to infinite scroll, at least while Marissa Meyer comments are considered: See http://www.quora.com/Will-Google-introduce-infinite-scrolling-to-its-main-web-search
Paul Gailey on March 30, 2012 5:15 PMI can't tell you how many times I was reviewing a paginated result set and said to myself, "Wow, this sucks because of all of these pages."
Wait, nevermind. I've never said that to myself.
Ronnie Overby on April 3, 2012 5:03 AMI understand and I agree with your points. But I don't see a better alternative for pagination.
You are right, when you are having thousands of pages, then Pagination becomes meaningless from a user's point of view (but not from SE).
I wrote a pagination tutorial for WordPress users without a pluging:
Paginate comments: http://bacsoftwareconsulting.com/blog/index.php/wordpress-cat/how-to-add-and-style-wordpress-comment-pagination-without-a-plugin/
Paginate posts: http://bacsoftwareconsulting.com/blog/index.php/web-programming/add-custom-wordpress-pagination-without-plugin/
Thanks for this great post.
What about cached ajax pagination with detection of scrolling ?
It's more complicated to implement on one's site but it would be nice.
For the sake of SEO it is much better to remove all pagination. When you have multiple URL's serving the same content your rankings will be diluted as Google deems the page to be duplicate content. For example, http://www.couponcodescout.com/newegg-coupon-codes you will notice multiple pages of very similar content. It would be much better to just to let users scroll.
Daniel Sayer on May 27, 2012 11:38 AMPagination certainly has some relevance when done for a specific set of items or else ts a nightmare for the browser.page auto load is a good option and it will also help user not to jump to 'nth' page to find what they are looking for.
Also as stated above it would also help in the SEO for improving the ranking.Good article that makes SENSE.
www.optionsconsultancy.com
Pagination was the single most annoying thing that happened to the web during the 90's, that is, until people started doing the horrible AJAX ad-hoc page loading.
The whole idea of arbitrarily feeding a user small chunks of data somehow doesn't smell right.
The user should be the one to decide if they want to see those 200k hits on one page.
I don't want to get back to my browser just to see it hasn't loaded everything, and that I still have to wait if I click somewhere.
A single hit might not be enough, maybe the user needs all those hits for their search?
Remember, searching is just a hack to work with unstructured information, designed to prolong our inevitable fall into the chaos which is the web.
Thanks for letting me know about such a good blog i really appreciate.
veste Alex Mercer
I work for a VERY large online retailer. I can't tell you how many websites have missed out on some very lucrative advertising dollars from us because I can never reach the "Advertising" link in their footer because of their never ending page. My rule now is, if I can't reach the footer in two attempts, I'm moving on.
Clifhaley on July 19, 2012 10:30 AMrepeated use of a mundane word. He had fun with the colorful terms invented by sports writers in particular. It’s clear to me, however, that all kinds of writers feel the compulsion to avoid repeating words when they write. buy facebook fans
But once you have thousands of items to paginate, who the heck is visiting page 964 of 3810? What's the point of paginating so much information when there's a hard practical limit on how many items a human being can view and process in any reasonable amount of time. search engine optimization
I must say I utterly disagree with the views and conclusions in this article. There are definitely areas where endless pagination can be a good idea, but by mentioning fuzzy web search results as an example, I think you've already pretty much exhausted that space of applications. And even there, power users might be very annoyed with endless pagination, e.g. in case the results are, though fuzzy, ordered according to some sorting criteria.
As for the problems of endless pagination that you mention yourself, fixing via JavaScript the issue that you lose your position in the list after leaving the page and returning to it, is more irritating than anything else. The browser will go through several iterations of jumping to the bottom of the page, loading more results and jumping on, depending on how deep into the list you were. If the jumping stops, there's no quick way to tell whether you've reached your previous position, or there's just a pause because of latency. Also, I've noticed that for about 90% of endless paginations I see in the wild—and on big sites, too, such as Twitter—the developers obviously didn't understand the simple fact that you mention: people won't be able to reach footers anymore. It makes a site look very unprofessional. Well, at least for Twitter, if you'll excuse my rant, it fits the rest of the site then. In my opinion, if you know where a specific piece of information would be found on a site (e.g. for Twitter, username and date of a tweet), but you still can't get to it without using external tools (i.e. Google), that website is an utter failure in both the design and programming departments. Twitter is one of those cases and really needs to either get their act together or just call it a day.
Anyway, once you get away from thinking just about fuzzy search results and to pretty much any other type of content that needs to be delivered in list form, such as posts in a discussion thread, or a list of a user's uploads on a site based on user contributions, these entities are ordered, usually chronologically. Endless pagination breaks a user's ability to jump ahead or back a given number of pages if they know where approximately in the list the information they're looking for is to be found. Take for example Soundcloud. They recently rolled out a redesign, where they replaced real pagination with endless pagination everywhere. I am following an account that uploads around 50 audio releases a week. Recently, I was looking for a certain upload from early last year. Good luck! Endless pagination means that while on the old system I might have jumped to page 50 or whatever, or clicked the "Last page" to start from the other end (since the account hasn't been active for much longer than a year), endless pagination meant that the same task would take several minutes of wearing out my poor mouse's scroll wheel. Luckily, Soundcloud still offers users the option to revert to the old site layout, which I had to do for the sole reason of endless pagination (missing out on a lot of great new features because of it). Not all your users are stupid, or entirely clueless about where their information is to be found. If you take (a) the information about the total number of results and (b) the possibility to jump to a certain part of the results directly away from them, you're stealing their time, you're generating an insane, unbearable amount of friction for them, and will probably lose them for good. That's why no serious database query system uses endless pagination. It's just not workable in real-world use cases.
As sort of a reconciliation, I would say that real pagination is not only necessary to accomodate crawlers, but that the option, should you then decide that endless pagination is workable and a good idea in your specific situation, should also be left open to users who want to switch over to that method.
Daniel Saner on January 26, 2013 5:00 PMReading some more comments, I agree very much with Kamran Ayub that much of it is down to bad implementations—on both real and endless pagination. And most of the time this is due to the reluctance of developers to give (power) users the functionality to search for what they're looking for.
For my Soundcloud example from above, I wouldn't have had that problem if it allowed me to search or filter by date. The same thing fixes traditional pagination. You can, for example, sort YouTube search results reverse chronologically, but not forwards chronologically, or search by a specific date range. This is one of my main annoyances with most sites out there. They don't give me enough power to search, to mine, to filter and drill down.
So far, when we're talking about advantages and disadvantages of either method here, we're talking about users having to "hack" their way around limitations because they can't tell the search script what they are really looking for. I very much agree with the article's author in that. If you could search by the criteria you actually have in mind (YouTube, show me all videos from February 2011 that are between 2:00 and 2:30 and in Spanish), then the question of real or endless pagination becomes rather moot.
So in the end I must say I agree with Mr. Atwood's analysis. If the results are relevant, no one will have to browse thousands of results. I still don't agree with the conclusion though. Endless pagination solves nothing. It just transforms one set of problems into an entirely different set of problems, and—my main concern in the post above—the new set of problems are harder to get around for power users (such as by manipulating URL parameters).
Daniel Saner on January 26, 2013 5:18 PMa few hundred items. But once you have thousands of items to paginate, who the heck is visiting page 964 of 3810? What's the point of paginating so much information when there's a hard practical limit on how many items a human being can view and process in any reasonable amount of time plumber in diamond bar
the point of paginating so much information when there's a hard practical limit on how many items a human being can view and process in any reasonable amount of time. Matawan Tax Return Service
The comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |
