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.

What is the best way to allow a user to increase the number of results shown. E.g. (Display 15 25 50 100)

It would be used on a system were the potential results could be anywhere from 15-300+.

I'm questioning if it's better to offer this, or attempt to find a balance that just displays a reasonable amount of data and then paginates after this.

share|improve this question
add comment

3 Answers

With the recent proliferation of variously sized displays, it has become common to offer something like: 20, 40, all results. The page size is fluid, extending down as much as necessary. With the 20 and 40 results per page, 20 being default, show previous and next buttons. The exact numbers used depend on size of results and what typically fits on one screen of mobile and tablet devices.

share|improve this answer
add comment

This all depends on how frequently you are hitting the higher end of the spectrum, but I do believe that adding the display size option is a good one to use. Although many people have fast internet allowing for small display amounts would prove effect for those on slower speeds or on mobile devices.

share|improve this answer
    
I find that offering the smaller size also helps with preventing users from getting overwhelmed with large tables of data. –  user17059 Aug 15 '12 at 20:54
    
Yes that is yet another advantage it is easier to work with and get accustom to smaller batches of data. –  kwelch Aug 16 '12 at 15:13
add comment

What about infinite?
Like, for example in Google search for images.

When you set a number of items per page usually there are two superposed scrolls:

  • The application More ... scroll, and
  • The window scroll.

We do it mostly without noticing, but it's complicated.
Ideally the items container would fit into the height of the viewport, and the user would simply scroll back and forth in a seemingly continuous items column.

Moreover, there is sort of a fear to send many items to the client, thus the limit: 30, 300 or whatever.
This is inherited from the ancient slow Internet with 14.4Kbaud modems.
Make the math and calculate how many bytes would be sending 10000 (10K) items to the client (browser). Then compare the resulting number with the weight of any Facebook or Linkedin page and you might not see a significant difference.
For a 200 bytes per item table, 10K items throws a total byte count of 2 millions, which is nothing regarding current bandwidth numbers.
This is a one time download, as any further scrolling won't need data from the server.
This is an important advantage in this architecture: you don't have every user banging the server for the next 30 or 300 items, unloading it and reducing the server's bandwidth waste.
Don't set the HTML in the server. A rather recent benchmark by flickr demonstrated that the best formats were csv, and JSON. You download the data in on of these formats, and set the HTML with a client-side script.

In cases when each row involves an different image, as would be in the list of articles of a e-shop, then you need to set a script to download only the images of the currently displayed items. The script would be triggered by a scroll event to download the images for the few currently-visible items.

Moreover, this design saves the user from having to choose a page size.

More moreover, this arrangement allows setting a local filter. Try this simple jQuery plugin https://github.com/riklomas/quicksearch especially the super_table example to get a glimpse of the response times achieved (you need to download it in order to run the demo).

I've been doing this (big table, local filtering) in desktop applications with success. Now it's totally possible to do it in the browser.

share|improve this answer
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.