My first network connection device was a 2400 baud modem. Practically speaking, that would allow me to sustain downloads at a rate of less than 250 bytes per second. This was relatively fast at the time; I'd been using my buddy's 1200 baud modem to connect to local BBSs before that modem-netting birthday.
To put this into perspective, the Yahoo! homepage, all considered, is somewhere around 470kB. On my early-90s era modem, it would have taken a little over 30 minutes (half of one hour) to download (in perfect conditions, without protocol overhead (good ol' zmodem), and if my mom didn't happen to pick up the phone during transfer).
For the past few years, I've had a 10 megabit connection (downstream) into my home/office. Under perfect conditions, I can pull the entire Y! homepage, and all attached media in less than half of one second.
In the early 90s, the Y! homepage was obviously much smaller—all pages were smaller—but even with a smaller footprint, many pages took a long time to load. I remember browsing with many windows open (browsers didn't have tabs back then... in fact, we barely had browsers (-: ), loading up a dozen or so pages before alt-tabbing back to the first one I'd queued up a few minutes before (on my 14.4kbps modem, by this time), to see if it had finally finished loading.
To overcome low connection speeds, lack of resources on the client side, and other factors such as connection latency that lead to slow page page loads, web pioneers came up with a model for allowing content to be delived in reasonable sized chunks that is still in use today: pagination. Long lists of (say "100") pieces of data ("search results") were separated into smaller pages (of "10"), including widgets to allow skipping to the next, previous and often any page in the set.
Well... mostly still in use today.
Technologies have helped us hack around the idea of separating growing amount of data into pages. Ajax, for example, allows the dynamic loading of the next set of results without forcing a page reload (often poorly... try bookmarking the result of many of these dynamic populations. Even Mobile Mail on the iPhone/iPod Touch allows something like this.
It seems to me, though, that web interface designers are stuck in this rut of showing end users a mere 10, 20 or even 100 items at a time. My 10Mb connection can handle a lot more traffic than you're sending; your server had better be able to deliver it (and usually, it can); my browser is allowed to allocate much more RAM; and I even like to think that I've microevolved the ability to parse much more data that I could a few years ago.
So, I ask you, fellow web professionals: is pagination still necessary? I obviously don't think so, but I'm not a User Experience guy, I'm a user (and also the guy who has to make the UX happen, and make sure your server can deliver the results mentioned above). Tell me what you think.
It depends. :-) A lazy answer, I know, but I'd hate to search Google if the results weren't paginated.
Oh, I agree about something with Google, where the result set is in the millions, not in the dozens.
I guess I should have said something like that in the text. (-:
S
In my opinion, pagination is still visually useful. At this point, we're mostly limited by ourselves - not the machines (ie: data transfer etc). Pagination breaks data up into easy-to-consume chunks, and on really big sections of data, keeps the processing-time low.
I lazily agree with Chris. I don't think pagination is no longer required, but I think we can do it better. Soup.io has implemented a pretty interesting way to do pagination without pagination: http://www.soup.io/everyone
Several people in the Habari community have recently tried adding a pageless design to their blogs, but I for one can't stand it. There should always be a firm end to every page. My scroll bar should stop when I get to the bottom, not continue endlessly.
We're used to pages. Pages are everywhere. From books to notepads to the web, everything is split into manageable chunks of data we can handle and comprehend easily. It's one aspect of common user interaction that I don't think should change.
Paging has to do with the fact that we humans often don't even need to see everything. If it's something like a comment list, it makes sense to show all of them. But if I do a search for something, I'm pretty sure I'll have what I need within the first dozen items, and everything else will be ignored. Delivering the entire resultset would be a terrific waste of bandwidth and processing power that can be very well be used to serve someone else.
We've been working on a UI for a new feature for our production products.
The data we expose to our users can be as large as 1-2MB. Our first prototype was without pagination and it made it very unresponsive not only because of bandwidth issues, but even on a gigabit LAN there were challenges with how well the browser could handle that amount of data (more specifically the Javascript engine).
So from my point of view there are definitely still many use-cases were pagination is a must-have. I am sure there are also cases where it's just a PITA. In a perfect world when pagination is preferred it is typically also a good idea to offer the user a non-paginated version...
Quite often people have to run their apps on shared servers with slow databases - or even limits on how many results might be returned. So yes, I think it's still needed, but it should be easy to change how much you want to see.
With dynamic grid widgets, pagination is less necessary. I've been playing with Dojo's grid component a fair bit in the last couple months, and when coupled with a good data store, pagination is not only unnecessary, it lessens the UI experience. Imagine a grid that pulls in data only as it's being requested -- pagination no longer becomes necessary.
That said, this is still *virtual* pagination, as you're only pulling a subset of results at a time. This is still necessary because pulling *all* results at once will lead to an unresponsive UI; the browser simply cannot build and manipulate that many objects in the DOM at once.
our customer in indonesia still using 52kbs internet connection, so pagination are really important in their cases. moreover i think pagination provide more cleaner data presentation.
The question is certainly valid. There are definitely cases where pagination is needed, because you might need a long list of fairly bulky entries.
With today's technology, would it enough for example, for a web app to send the top 100 entries? A somewhat rich UI can allow the user to scroll through them 10 at a time. Then if the user seems like they're scrolling near to the end of the 100 entries, the UI fetches the next 100 using AJAX.
Occasionally we scroll through many search results in a Google search, but most often we find what we're looking for in the first 2-3 screens. If not, we start over with different search criteria. So why not optimize the user experience for the most common case, and allow indefinite scrolling as an extra?
I hate paginated news articles, with every page you transfer tens of times more ads than content, so it would consume even less bandwidth without paging.
Although for longer lists paging is OK. The idea with never ending lists (soup.io etc.) is quite nice, but after scrolling many thousands of posts it would be more difficult to go back to some specific point in the past. You would need to scroll all the way back or start from the beginning again. Pagination would be easier...
Take a look at one of the sites I work on http://www.thefirstpost.co.uk/
It has won awards and gets constant praise for its uncluttered look and multi-columned paginated layout (a bit like a real magazine / newspapaer).
We have had some top UI experts from the US and UK talk to us about our site, the funny thing is the UK and US have completely opposing views on pagination and good UI.
In a lot of sites I have been collaborating with, pagination is not needed anymore.
It's just the editors that ask for paginated everything, so that they can shove down the users throat a huge quantity of ads...
Having said that, I think separating data in small subsets presented to the user makes a lot of sense, if not resource-wise, at least interface-wise. Scrolling trough enormously long pages is pretty annoying for limiting factor such as
- the size of the scrollbar handle that gets too small
- going to the top/bottom quickly is limited to using keys, as doing it via mouse takes too long (and many users only use mouse!)
- putting links to go to top/bottom on every line is visual clutter
- going back to line X after eg. you moved to top is hard, as visual memory will not help much when X is between 1 and 1000
A study published recently showed that users are interested in the first 3 results when searching on google.
I see less and less use for pagination, honestly who wants to view page after page 50 times ? Better search to present relevant results is more interesting imho. You can always offer oxporting to excel/open office to view large resultsets.
Ajax is great but not that great for pagination. Eg printing is a challenge. And getting all results in one big page when doing a google search isn't a great option neither.
Tomas had a good point there, although he was complaining about it, seeing it from the angle of an end-user ;-)
Many websites make money by delivering ads for each page request. When you offer paged content, it makes sense for them to deliver the data in the smallest chunks possible, so the user has to make more requests. When each request means additional revenue, the more the better :-D
In an intranet setting it makes a lot less sense these days, though.
It depends, Pagination in order to display more google ads for a fixed amount of content is bad. Pagination in order to keep not relevant information off the screen is good (why blogs should have pages).
Clearly it isnt desirable to pull back millions of search results, or if each row in a table requires server side resources, it is also not desirable for the server to even calculate all the results. So pagination in order to reduce the amount of data is still viable today. The only thing that is changed is that we no longer require pagination in order to reduce the amount transferred on the wire.
I couldn't agree more with aswad32. While people in countries like europe or america, have bandwiths lke 10Mbits, there are still people who are connecting to the internet with 56k modems. So the bandwith did not evolved yet enough to support a web without pages.
But I agree that it's irritating to only show 10 results between thousands while you can show 50 easily. SO I guess this is the part which must be improved, it will be better to show how much I want to see in a page, say 10, 50 or all.
I'm sure most of you have used google rss reader for a time. I'm still using it and the best part is that, while you scroll down through rss feeds, google fetches new ones and you never get to the bottom. I guess this kind of pagination might be useful. Fetching data when only it's needed!
It gives you a better experience while you looking at the limited amount of results, it's easier to remark something and once you get to the and of that limit, the next result set is already here and you don't have to paginate to the new page as the web site has already done what you were needed to do.
I've seen a number of implementations of pageless search results. Often it is a lot harder to get a good grip on where in the search result you are when not using paging. As Tomas Markauskas points out it is also very difficult to jump to a certain point in the search result. This is especially true when the search result is large, as in the above mentioned Google.
However, I think the question might have different answers depending on where it is used. In some administrative applications pagination just don't feel right.
As Chris stated, it depends. I don't think it's time to throw it out of the toolbox, though. My main reason, aside from obvious things that need pagination, is that in our search to 'get rid' of pagination, we destroy mental models of users who used to know how to browse large sets of data.
Emails are paginated, Photo sites are paginated, Video sites are paginated, etc. While we may think there is something better, I'm just not sure it's time to give up on it for the sake of the end users. So my reason lies solely in user experience, more than 'oooh, we could do it this cool AJAXY way'. Not that AJAX ways are bad, just saying you really need to think about the end user navigating the site/application.
I think that you forget about books. Yes, it is very old technology, there are not problem to create bigger pages and make pages count smaller. But stop you will have same size of information! and small chunks like chapters and pages make book more useful.
Also you forget about bookmark, how you will bookmark small piece of information if your pages have 1000 lines?
So, I think you have broke concept.
Pagination is part of user interface optimization and size of information not loaded data make sense here.
Do you use YouTube? It example, it is simple to have page with many movies, but you will see only one. You attention have limit! It is one of cases why books have small size.
Hmm, well looking at it from the other side of things, is it always necessary to return so much data that it has to be paged? Could it be possible that you should constrain the query in such a way that they can pull back the information they are really looking for?
For example, when I go to my email, its most likely I will only want to see the new emails. Why show me all the 'read' ones? Sure I could be a popular guy, and even if I got a few 100 emails, maybe just show me what has come in within the last hour, or last time it was checked, with an option to 'view more'? You can start with a few intelligent assumptions, then move from there to user patterns and see what people need. Pagination sometimes ends up as a lazy way to avoid filtering results. Granted, the user has to be more specific, so where you can guess correctly, do it, and when you can't, encourage a little work ;)
I think always assuming that the end user was EVERYTHING might be a mistake on our part as developers. If we can make it easier for our users to get what they need, they will use our programs more.
Pagination is only going to get worse - why? Advertising. An increase in page views equals more ad impressions. Especially in the header/footer of a site. The only reason news articles on the top portals are paginated is to increase ad impressions.
Of course, you can still refresh ads with AJAX, but it requires more tech resources to do this. For most sites the header and footer is treated as a separate entity (in a CMS) so a page reload is needed to serve a new ad anyway.
Well it depends on what you are dealing with. cooliris.com for instance takes away the pagenation on google images and allow you to browse through the pictures much faster.
When it comes to text it depends what you are writing about.
In my opinion, pagination is of more importance and use these days due to faster connection speeds. In the past, it used to be very frustrating slowly clicking through pages of results. It was more convenient to have many list items on a single page so that the page refreshes could be kept to a minimum.
However, now that we have faster connection speeds, we can keep the amount of data to a controlable and comfortable level through the use of pagination. Pagination thus is more of a UI element than a necessity due to the loosened constraints of bandwidth.
Agree with Steve, not only do they want a refresh to re-display the ads, but they also want your eyes back above the fold, where the ads are.
I guess it's all within context, I have google set to return 50 results, it means I can search within the page and I rarely need to hit the second page.
Just because you're on a 10 meg connection, doesn't mean the rest of the world is. I'm sat here at work on a connection that barely reaches 1 meg on good days, and that is split between 8-9 people.
Please, let's keep pagination, for my sanity if nothing else.