2

I am developing a web 2.0 website, with a search page that contains a cachable table which can retain the searched data.

How can my page manage if the results return a lot of data?

There are 2 solutions:

  • 1st solution: Using pagination, the search result will list all pages & when the user clicks on a page then all results of that page will be stored in the table, like this:
TextBox:__________

[Search Button]

All result pages: [1] [2] [3]...(suppose users click on page 1 & then page 3, then-->)

The following table contains page: 1, 3

ItemID - Item name....

12 - xxx--->data from page 3
13 - vvv--->data from page 3
11 - ooo--->data from page 1
10 - kkk--->data from page 1
  • 2nd solution: just use a Next button, and when the user clicks search it will load the most relevant data first. If there additional data, then a Next Button will appear, and clicking the Next button will load more data,
TextBox:__________

[Search Button] [Next Result]


ItemID - Item name....

12 - xxx--->data from page 2
13 - vvv--->data from page 2
11 - ooo--->data from page 1
10 - kkk--->data from page 1

With the 1st approach, the server is a bit slower (maybe a few millisec) because it has to spend time counting the total rows. It might be harder to code, but the user can see an overview of how many results.

With the 2nd approach, the server is a bit faster (maybe a few millisec) because it doesn't have to spend time counting the total rows. But the users can't see the overview of how many results. Probably easier to code.

In both solutions, the users can sort and filter the accumulated data.

If the table can accumulate the data, then will pagination be necessary? Which solution is better?

elemjay19
  • 1,288
  • 12
  • 25
Tam
  • 77
  • 5
  • Is your question about how to implement it or what is better? – Mervin Feb 09 '14 at 18:07
  • what is better? – Tam Feb 09 '14 at 22:21
  • You need to answer a question if user needs to directly navigate to a specific page. E.g. in sites like Ebay, and sorting auctions by e.g. price, seeing that navigating page-by-page does needs next bunch of pages to be skipped, user may be interested in skipping them to faster get to this lower price s/he might be interested in. In some cases, though, this may be not important. Few miliseconds will not be important for users so it's a good price to pay for major usability upgrade. Thus, the main question here is what your users expect. – Dominik Oslizlo Feb 19 '14 at 08:12

2 Answers2

1

To me the 1st approach is more seducing. As you said the user can have an overview of how many results the search produced, allowing him/her to:

  • Guess quickly if more filtering is required (quality)
  • Figure out if the website proposes a large offer (quantity)
  • How many time it will take to review everything (cognitive load)

As Dominik said, few miliseconds will not be important for users.

Tony Da Fonseca
  • 56
  • 4
0

The benefit of a "paged" approach compared to a "next" button is that the user can easily skip from e.g. page 1 to page 7.

Are there ever any circumstances where it is useful to skip from page 1 to page 7? If not, use a "next" button, on the principle that all else being equal, the fewer widgets you have to put on screen the better. (Or better still, make that zero widgets with infinite scroll, if that fits with the rest of the site UI.)

(A more natural positioning for that 'next' button would be at the end of the results table, which is where the user would be looking when they need it, rather than next to the search button where it could get confused with the search itself.)

The point about counting the total number of results is a red herring -- you should probably be presenting that information in either approach.

Daniel Beck
  • 4,592
  • 14
  • 22