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.
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.
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:
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.
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.
