-1

I have a web application that retrieves and displays records from a database. A user's query could possibly match thousands of records; in such cases, it makes sense for the user to refine his search.

In the case that the query matches hundreds of records, it probably makes sense for the user to browse the records. The thing that bothers me is that the web application displays "pages" of records. In the context of a web application, I believe that paging is a horrible, horrible, way to display this kind of data.

Imagine the following scenario:

  1. User runs a query: application indicates there are 20 pages and displays page 1.

  2. User clicks on to page 2, then page 3.

  3. User realizes that the record he was seeking is on page 2. User clicks on to page 2 again.

  4. User thinks that he saw a similar record on page 1. User clicks back and forth between page 1 and page 2 repeatedly to compare the records.

With a web application, each page change necessitates loading an entirely new page. The end user probably thinks of it as just loading more data, but to the browser, this is just as much work as loading an entirely different page. Furthermore, when the user cycles back and forth between page 1 and page 2, the same data is being loaded from the server over and over again.

It's insane that with a modern computer equipped with billions of bytes of memory we have been conditioned to think of it as being normal for the computer to reload (over a slow connection with high latency) textual data that would take up megabytes at the very most.

I have an idea to use JavaScript to automagically load new records each time the user scrolls to the bottom of a page of records (There would be no paging links for the user to click on - the records would simply load as the user scrolls). This sounds nice; but one drawback that comes to mind is that it would be difficult to print the page without first having to click on to a "printer-friendly" view.

What other ideas are there for stuffing a database application into a web document without using a clunky paging system?

hrbrmstr
  • 77,368
  • 11
  • 139
  • 205
Vivian River
  • 31,198
  • 62
  • 198
  • 313
  • 5
    Pleaes tidy up your question. I don't need the history lesson and you copied and pasted the same paragraphs multiple times. – Layke Nov 21 '11 at 18:15
  • The infinite scroll thing that you mention already exists. Just google "infinite scroll javascript" and you'll find dozens of examples of this. Google already implements it with image loading, as do many, many, many other sites. As for printer-friendly, just pass in a "print" parameter to the page, and if so, don't do any pagination.. just load everything up before it prints. – Jemaclus Nov 21 '11 at 18:18
  • @Layke, I wanted to point out exactly what is motivating my question so that I would not be misunderstood. I'll give some thought how to tidy this up a bit. – Vivian River Nov 21 '11 at 18:26
  • Are thousands of records visible at once useful to a user? Perhaps your list is not specific enough or doesn't implement the right searching/filtering functionality. – James Nov 21 '11 at 18:28
  • The user may craft his query to be as specific or narrow as he chooses. In some cases, a user may very well legitimately need to query for thousands of records. Generally speaking, if a query retrieves that many records, the query was not specific enough. – Vivian River Nov 21 '11 at 18:33
  • I shortened your question considerably while responding to multiple flags. Please consider refining it a bit more. – Tim Post Nov 22 '11 at 02:20

3 Answers3

1

I would go with the "automatically load new records as user scrolls to the bottom of the page." It's by far one of the most user-friendly method in my opinion.

For printing, you could rig each paginated set so that they receive a "no_print" class or something as new a set is loaded. Dynamically add/remove that class as the user scrolls back up.

badp
  • 11,409
  • 3
  • 61
  • 89
simshaun
  • 21,263
  • 1
  • 57
  • 73
1

Well from the start I was going to suggest adding new records as the page is scrolled. If you are worried however about getting really long pages. The solution would be to hide the top records so there is only ever a max number of records showing. However, you would need to give the user the option of what the max is or an option for no max that way everything shows. Also, depending on their choice you may still need to offer a printer friendly version. Another note is it would probably be best to add a thing on the side telling the position like showing records 35-85 of 200.

qw3n
  • 6,236
  • 6
  • 33
  • 62
1

So in my application, I have millions of records which the user can view seemingly all at the same time.

I load more records by requesting the same URL but changing the request headers.

Here is how you can implement something.

Let's assume that you want to list all the animals in the world in alphabetical order. You don't want to paginate by having a "< Previous 1 | 2 | 3 .. 9989 Next >" bar at the bottom.

  1. You would start off and immediately query your "resources" route which will return a set of animals: GET /resources/animals.

  2. Your request would include headers which say what it is exactly you are requesting. For example, add a range: 0-24 header. Related question: adding Custom HTTP Headers using Javascript

  3. On the server side, you can figure out that the user is requesting the items 0 to 24 and you can respond back with Response Headers telling him what you are returning back like this: returned: 0-24/12000000. This tells the client that you have returned 25 items, starting from item 0 up to item 24, and there are still 12 million items left.

  4. Render the items that you have received from the server.

  5. As the user scrolls further down the page, query the next set of items. Using math and figuring out what is currently in view, you can calculate what "page" the user is viewing and can then request results which correspond.

You can see this working in practice here on the Dojo examples.

Read more about the subject.

Community
  • 1
  • 1
Layke
  • 51,422
  • 11
  • 85
  • 111