[Cbeppe]

Hi,

I have encountered a situation where I display a potentially large amount of data (list of files) in a HTML table. While this is currently not a problem, I foresee a time when the table may contain X-thousand rows, and at that point, it would likely turn into a huge performance hog.

Naturally, I have considered some solutions to this:

* PAGINATION: A simple solution, but not very elegant IMO. Personally, I hate refreshing the page to look for something in an alphabetical list. I consider this to be the very last option.

* AJAX: Dynamically loading 50/100/200 rows with a "Button row" on the last row. Slightly more elegant than pagination, but it may still cause a substantial delay. Especially if the file is in the last part of a large list (Try finding a friend on Facebook from the list of all your friends).

* DYNAMIC SEARCH: AJAX-style search bar that filters out results. Great for finding something specific, but doesn't solve the browsing issue.

Any of the above solutions could be used, but I'm interested in seeing how others have handled this in the past. This post is not an urgent call for help; instead, I'm just looking for suggestions.

Thanks for taking the time
Cbeppe.

This post has been edited by Cbeppe: 24 June 2012 - 04:30 PM

[Martyr2]

Welcome to the world of "big data". You have covered three of the main solutions and often times we use one of those three. Sometimes we make a hybrid like an AJAX method where you first cut down the list and then browse. For instance get me rows starting with "A" and then go into a browse mode browsing through those with "A". Want to browse more, select items starting with "D - G" and browse those. In other words, use an index approach to index into the set and then browse.

The idea is to cut the whole into the most appropriate subset and then switch mode into whatever makes more sense at that time.

I also have no problem with pagination. You could make an AJAX style pagination which might appear a bit more response and won't require an entire page refresh.

[The Architect 2.0]

as a user, i personally like 'endless scrolling.' Most implementations have been respectable in performance and the persistence of the data allows me to easily ctrl+f

[Cbeppe]

@Martyr2: I had a feeling that this is a common problem. I like your index idea since it makes searching and browsing much easier than choosing a page number. The only issue I have is that I would like to be able to sort by different variables than the name (for example size or type). I know I didn't put that into the first post though, but like you said, it's about dividing it into the most appropriate subset.

@The Architect 2.0: I totally agree with you, I'm an avid user of ctrl-f. The issue is that if there are several thousand rows, the page would not perform well. One solution to this that I can think of would be to load the data itself with AJAX using JSON and then use Javascript to add each row to the table. That way, a lot of HTML <tr> and <td> tags could be omitted when transferring.

Thanks to both of you for answering! To everyone seeing this, feel free to contribute any ideas. I'll come back and show what I came up with.

[Martyr2]

The Architect I think is referring to lazy loading your rows. So as you scroll down, before you reach the bottom you would make an ajax call to load more fully rows to the table. One place that uses such a mechanism is right on http://www.dzone.com. If you scroll down the articles on the right will seem to continue forever.

This too is an option.