Should pagination be capped in web app search results?

Question

Search results can be a funky thing to design sometimes when it comes to the value of results for a user. IN this Web App I am helping build, the global search bar, when searched, can lists results that include; books, resources, devices, blog content, support, etc..

Because We are not a google search engine, is it best practice to say that there should be a cap in the pagination? When you dive in deep into the search results it almost becomes a browsing experience. Do we think users would go 17 pages in to find a book they were searching for, or perhaps do a re-search or drill down browse.

Answer 1

You might not be Google, but the fundamental principles of search remain the same: users are looking for a specific piece of information, and want to find it as quickly as possible.

Due to the relevance in search results delivered by the market leading search engines, users expect to get the result they are looking for on the first page of results and will typically not keep looking beyond page one because their expectation is likely that the remaining entries are not relevant.

It's worth noting that the vast majority of clicks on the major search engines are on results on the first page, particularly the top 5 or 6 entries: http://searchenginewatch.com/article/2049695/Top-Google-Result-Gets-36.4-of-Clicks-Study.

If a user has made it more than a few pages through your results, you're probably making them do too much work to find what they want, and you may need a better search solution. In this context, low caps on pagination are useful to stop the user from getting lost down the rabbit hole - you probably want them to re-search with better parameters so that they don't waste time trying and failing to find what they want.

The counter-point to this is that arbitrarily restricting your search results may prevent some users from finding the information they need, especially if they're not good at searching or your search result is poor at matching queries to results - in which case your search probably still needs improving!

Answer 2

Just because users might not actually page through all 127 pages of results doesn't mean you should restrict the number of pages returned.

For example; if they've searched an eCommerce site for 'nice' then there probably are hundreds of pages of results. Telling them there are hundreds of results is the truth. If the user wants to wade through all those pages then who are you to stop them? You're not forcing them to do so.

A better approach than worrying about whether or not to show numerous pages is to ensure that you have your search indexing set up correctly, and that pages that don't need to be searched aren't featured any longer (such as old promotional content pages for features that have long since expired). If all the pages that need to be searched are indexed correctly then they all deserve to be featured in search results.

Answer 3

Pagination isn't necessary the best option (vs scrolling) and either way, sometimes users only check the first few results, sometimes only the first pages of results and sometimes users speed browse through 100s or 1000s of results - it all depends on how much the user knows about what he/she is looking for.

If you are looking for something specific (e.g. a book you have heard of) you may try a brief search and if you don't find it pretty quickly, you may try refining the search (possibly a few times until you find it). If refining the search doesn't help (either because you keep ending up with loads of results which don't include what you have in mind in the first few or you end up with no results or a few results which are all irrelevant, you might browse through 100s of results looking for a match.

If you are looking for something vague or not well defined (e.g. unknown books that cover a specific topic or an image similar to something you have in mind), you may go through 1000s of results until you find one or more close matches.

Answer 4

Pagination is a hack. Infinite scrolling has its issues-- in particular when the scroll bar changes to a new 100% setting as you use it-- but that is still much better than the click, click, click experience of paging. Best would be to calculate how many results total on page load, and set the scroll bar to match the length of those results, then load the results on the fly as needed.

Pagination is a work-around for the fact that it is not always feasible to send all results in the first view, which would typically make for an ideal user experience.

dhmholley is right that users want relevance, so focus on that above all else. Scrolling is also a hack, to make up for the fact that we don't have screens the size of buildings or eyes that can read infinitely small text. So the overarching goal is to get the best, most relevant results to users in the first screenload of results.

That said, the concept of "milestones" or waypoints within a very long scrolling result is enormously valuable. For example, if I have infinite scrolling, how can I find that one screen with the two things I thought were right? If a long result set breaks results into numbered "chunks", then this aids the user having reference points to return back to.

For example:

--- MYSEARCHCRITERIA : Page 1 --- result1

result2

result3

--- MYSEARCHCRITERIA : Page 2 ---

result4

result5

result5

--- MYSEARCHCRITERIA : Page 3 ---

... you get the concept. Breaking the continuous result into numbered chunks is still helpful even in a list that is not actually separated into pages.

Oh and don't forget to reflect back to users what it is they searched on!

Answer 5

Yes you will need to be aware of the 'cost' of pagination. Both technical and user friendliness terms.

My advice:

1) Make the search function as effective as possible so that it likely to return useful results early in the list. If they were looking for a particular book, why might it appear so far down?

2) Offer facets that allow the user to narrow the results based on clear criteria. e.g. Product type, genre, price range etc. One of the biggest benefits of this approach is that the user feels like they are getting closer (the scent of information) with each action. If they are flipping through pages there is no sense of progress. This also signals that the products are organised in a logical fashion. Users may learn the structure over time.

3) Pagination offers the user some sense of the amount of results returned. By using facets you can both show the magnitude of the results plus give them a clue to how many results will be shown if they select a facet.

4) Take a look at the way sites like Pinterest work. As the user nears the bottom of the results a new batch is progressively loaded. The first time the user needs to select the 'Show more' button to load the next batch. This is a friendly approach with the added benefit of only loading additional results for those users wishing to see more. This should reduce the load.

Some further points to note:

• Google estimates the number of results and pages. Can you do the same?
• Pagination can allow users to return to a particular page. Ask yourself whether this is needed. I find it often isn't. Plus, the results can change.
• Can you paginate a block at a time - e.g. 5 pages. Only introducing another block of 5 when called?