Web displays: Paging vs. long tables

Question

It seems that the trend in web design is to provide paged output, where long tables are displayed a page at a time. My customers don't like that, and have requested that the web sites I design for them show all entries in long tables. The arguments for paging seem to be mostly based on the performance hit of displaying long tables, and this is less of a concern in a high-bandwidth corporate intranet. Arguments against paging include the ability to print the entire table, do string searches against the entire table, select arbitrary ranges from the entire table for copying, etc. I've pointed out that these features can easily be added to paged web designs (e.g. a print button that prints the entire table, or a button that creates a CSV file of the the table), but the paged output still seems inconvenient to them. Our typical table is about 100 to 600 items. Obviously tables that would be significantly larger would probably have to be paged.

Questions:

1. What is your experience with personal or customer preferences for paged vs. full output in long tables?
2. Web design tools seem to be pushing the paging paradigm. Are they out of touch, or are my customers unusual?
3. If you're thinking "It depends on the length of the table", what threshold would you use?

Answer 1

Why not simply have it be a user configurable option. It sounds like you plan to essentially implement both anyway.

To be honest I think that no matter which you choose someone will complain. At least with it being user configurable you have the ability to put it back on the user.

Answer 2

Best solution: Don't provide lists with more than 100 items.

Usually your user doesn't want to read more than 100 or even 600 items. They just don't care. They are searching for one (or possibly a few). Make sure that there's a way for them to get to those items without visual-grep-ing through the list.

And if your client insists on displaying all items, then provide paging with a configurable page size and let him enter "100000 items per page" if he wants to.

Answer 3

1. I love long one-page listings. One of the few reasons I can see for paged listing is the ones you point out about performance.

2. I think your customers are very usual and in-touch.

3. The threshold would be about page loading times. When the server can't produce the full lists fast enough or when the lists gets so long that the browser slows down. (The latter can happen for quite short lists if you have non-a-tag hover stuff in your CSS and the browser is IE.)

Give the users a powerful search function and they'll narrow down their page lists themselves.

Answer 4

One of the seminal books on web design (sorry, I forget which one) used to say not to count on your users scrolling down because most of them don't know how or can't be bothered. I think a more recent update says that while is is true for the general public, certain sectors of more technical users can be expected to scroll down and you can make pages that require scrolling IFF (if and only iff) you know your users can handle it.

Answer 5

I can understand your situation extremely well. I have been in similar situation. I moved a business workflow from being man managed to an automated one. Initially it was carried out using excel spreadsheets. The stakeholders for my software were in the age group of 55+ they dont like anything ajaxy or any of the UI patterns you are talking about. It such cases data retreival logic can be optimized. Any table that touches the 1K mark or has item like image blobs or things like that should be shown in parts from a performance point of view.

1. long outputs slow rendering and will be performance leech
2. Customers dont want to changes most times and customer is always right unless u can convince them.
3. I have put forth my threshhold but it also depends on the content of the rows.

Happy Coding!

Answer 6

Provide a default page length, and a configurable parameter (e.g. in the query string for programmatic use, and/or a form on the webpage for interactive use) to control how many listings are in a page.

User flexibility is good. Texas Instruments has a parametric search tool for electrical engineers to find ICs that meet certain technical characteristics, and they include a link both to "show all" in a webpage and "download all" as a .csv file. That's a good model, kudos to TI. Ditto to flickr; their API lets you control (to a large extent) how many results show up on a web service call.

I personally HATE websites that default to 10 listings per page with no way to increase it. It takes FOREVER to browse them, & I'm willing to wait longer if I can get all the stuff at once.

If it's an interactive webpage, I would consider going to an AJAX solution that downloads 100 at a time so there's an indication of progress (and the user can stop it if there are 20000 results).

I agree with PEZ, it's all about responsiveness.