Pagination in a table showing lots of rows in a thick client (application)

Question

The application which I am working on requires to show log of all activities that has been performed by users. The log table will get long as the application is used. User can select rows and print or even copy them to clipboard.

In this case, is it better to load all the entries at once or provide pagination? If pagination is provided then should it be conventional google like pagination or lazy scroll pagination? Please note that user should be able to select certain rows and copy or print them.

I came across a discussion (https://stackoverflow.com/q/5346777/3867200) which talks about websites but I am looking specifically for thick client applications and performance factors for both may differ.

Answer 1

Even for a thick application, it is not always about how much load client can bear. There are other aspects you must consider when you trying to introduce pagination. Nielsen Norman Group talks about that.

Performance

Loading all data at once will increase your initial load time, put burden on network. It would be unnecessary if user is not going to go through the entire data set. Especially if these are logs, then user might be interested in a recent actions he performed, loading entire data is not advisable. How do you plan to check for stale data? What is the limit you are willing to push a single call for data? Pagination almost always helps in these aspects. Your thick client does not mean, it has to make less calls to server. Where it is logical it still makes sense to get fresh data from server.

Responsiveness

If you are okay with initial load times, you will be able to serve the content in most responsive manner if the data is available on the client side. But even then it has limits. Any UI component (e.g. grid) will have upper limits of columns and rows before it starts to show lag and sluggishness. So you will have to negotiate with technical feasibility of how much data should you have on client side.

Nature of pagination

You might be interested in what Nielsen Norman group has to say about infinite scroll. It is not suited for all websites. There are efforts you take for infinite scroll, the reward (technical or usability specific) should be worth the effort. Also it important to see how frequently the paginated data changes. In other words, do specific page numbers mean anything for the user in short time span.

To surmise based on some assumptions about your use case, I feel your data is going to change pretty fast (assuming a lot of activities create a log entry). I would advice a infinite scroll, latest first. This will help multiple selection across pages too. I would also advice to tweak and play with page size until you get the right number of results users are interested in. Please correct me if I am wrong, my assumptions may not be correct.