Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Does it make sense to let the user chose how many items are shown per page? Or does it make sense under certain circumstances? When? When not?

This is how some big websites handle it:

  • Google: Used to be in advanced search, doesn't work with Google Instant
  • Bing: Can be set in preferences
  • Amazon: Nope
  • Ebay: Yes, looks like this:

Ebay items per page

My Impression is that this is a remnant from the old days when the number of items had a real impact on the loading time (so you would generally have it low and allow users with more bandwidth to set it higher). But many people I talked with want to keep the feature. Any thoughts? Pros and cons?

share|improve this question
3  
StackOverflow also does it, so it must be right. :) j/k –  John C Jun 8 '11 at 15:31
add comment

4 Answers

up vote 9 down vote accepted

I think pagination is another one of these cases where a good default value makes all the difference, and - as Amazon and Google show - it's then even possible to keep the burden of choice from your users altogether.

In my opinion, a selectable value for the number of items per page really only makes sense if that one page contains multiple conflicting requirements - e.g. providing the user with a quick overview over lots of data and showing lots of details of single data items without overwhelming the user.

In this case, an underlying problem may be that the purpose of this page is not clearly defined.

share|improve this answer
add comment

User-defined pagination seems right to me, at least in the context of tabular data.

For instance, consider the tables in Google Analytics:

google analytics table pagination

I presume many would find the table of data less user-friendly if you weren't allowed to set how many rows should be displayed.

share|improve this answer
    
I agree completely - but isn't that just the case because Analytics doesn't show enough rows per default? Why not just always show 100? (side note: It's really annoying that it's never saved; drives me crazy when I use Analytics!) –  Phil Jun 8 '11 at 15:21
    
Good point about remembering your last # of selected rows. Seems to me Analytics tries to show enough rows to comfortably fit the page, so I don't have to scroll up and down a huge page. Info in chunks, rather than one blob, which seems aesthetically good to me. –  mg1075 Jun 8 '11 at 22:01
add comment

The driving factor that determines the optimal amount of items displayed per page is performance. Making this parameter configurable can really help the end user. For example, if a user is accessing an application through a VPN and/or on wireless, their throughput could be diminished, therefore they would rather load 20 items per page rather than 100. They would want to load 100 items per page is they were on the local LAN.

Even though this pattern may be remnant of "old times", it still very much has an application depending on environmental factors. Best bet; find a good default that would satisfy the majority of your users, and let them choose if need be.

Also, keep in mind that poorly implemented products or slow connections could timeout on a page load if it takes too long for the data to reach the front-end. Selecting the items shown per page can help mitigate this.

share|improve this answer
    
+1 for slow connection speeds: With mobile devices connecting with 3G the loading time could still be a relavant factor. –  Phil Jun 9 '11 at 7:51
add comment

my personal choice will be to eliminate the concept of item per page and also get rid of the concept of pages.
just display all the items that fit the current portion of the page the user see. then auto paginate (autoload) the rest of the result as the user request them scrolling down (like facebook loads older posts).

I'm rewriting an application which had pagination of datagrids and a user configurable "item per page" value. Now the new application only have "infinite" auto pagination linked to the scrollbar. the feedback is very positive till now.

regards.

share|improve this answer
    
I would be careful with the infinite scroll pattern depending on the application. This pattern may be useful in news feed like situations when the user is just scrolling through content to parse. I think it is a different consideration when you are dealing with tabular data. –  Tom R Jun 8 '11 at 20:13
    
which are in your opinion the drawbacks on tabular data? I've not found any of them for now. it is much more usable imho. If I just want to "jump" back in time (suppose the data are sorted by time) I just scroll up/down and it is much faster than going through all the pages. –  ALoR Jun 8 '11 at 20:32
1  
I think there are drawbacks, especially in my case: It's very likely that the users goes back and forth from the result page to the "product view" several times (classified ads) and having no pages makes it very hard to orient yourself. Plus (depending on the browser) the loading behavior when using the back button can be very annoying (or in the case of facebook just not work at all; only the first set is loaded again). So eliminating the paging isn't an option at the moment. –  Phil Jun 9 '11 at 7:49
    
I somewhat disagree with the concept of jumping back to specific data. I believe users would rather select "Page 7", knowing their data is there vs. scrolling down for an estimated 7 "loads". It depends on how the data is sorted... Although, I think the issue with accessing the right data easily goes beyond the scope of this discussion. I would rather help users by allowing them enter a search term or use a filter than making them remember the location of a certain piece of data. This notion is complicated further when the data is dynamic. Slightly off topic though :) –  Tom R Jun 9 '11 at 11:22
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.