One of the key insights to emerge from research into human information seeking is that search is more than just finding: in fact, search tasks of any complexity involve iteration across a number of levels of task context. From information retrieval at the lowest level to work task at the highest, searchers engage in a whole host of activities or search modes in the pursuit of their goals.
Of course, locating known items may be the stereotypical search task with which we are all familiar – but it is far from being the only one. Instead, for many search tasks we need to analyse, compare, verify, evaluate, synthesize… in short, we need to manipulate and interact with the results. While the previous post focused on informational features, our concern here is with interactivity. In this post, we consider techniques for managing and interacting with search results.
1. Pagination
One of the fundamental principles we explored earlier was the trade-off between detail and screen space in displaying search results: too detailed and they risk wasting valuable screen space; too succinct and vital information may be omitted. But no matter how compact we make them, at some point there will inevitably be too many results to display on a single screen. When this occurs, the common solution is to apply some form of pagination.
Pagination confers several benefits: it limits load time (by dividing the results into manageable ‘chunks’); it provides a measure of how far through the set the user has progressed, and shows how much further they can go. However, implementations vary considerably, with Google, Bing and Yahoo all offering their own distinctive interpretations:
What they have in common is a list of numbered pages (with a highlight on the current page) surrounded by links to “previous” and “next”. But they differ in that Google uses the opportunity to further reinforce its branding and idiosyncratic use of the Google logo, whereas Bing and Yahoo deliver a more immediately usable design through the use of larger, clearer targets with a visible rollover behavior. These implementations differ further when applied to the mobile context:
Google, for example, maintains consistency with the desktop by using a control which differs little in appearance and behavior; loading a further 10 results each time. Bing, by contrast, offers a solitary link to “more results”, which returns a further page of results that load on demand. This means that the user can simply scroll to the bottom and the next set of results will be appended, without reloading the page. A similar approach is seen at Yahoo, in which 10 further results are appended to the current set on each invocation of the “Show more web results…” button. Interestingly, these approaches are now migrating to the desktop, with Google Images and Twitter both offering “infinite scroll” search results rather than discrete pagination.
While infinite scroll offers a more seamless experience (minimizing disruptive page reloads), and forms a natural expression of the fluid interactivity of smartphones and tablet displays, it does have a number of drawbacks. First, it is much harder for the user to determine precisely where they are in the result set or to navigate to a particular section. Second, it is no longer possible to bookmark an individual page of results.
Note that in all the above examples there is no control to navigate directly to the first or last page. This is because on the web it may not be possible to calculate the exact number of results for a given query, or worthwhile offering access to the last page in the list (e.g. if they are sorted by relevance). Google, for example, does not serve more than 1000 results for any query. By contrast, for more modest collections such as online discussion forums and other community sites, it may be possible to allow more direct access to the complete result set. In such cases, the pagination controls may be augmented with options to navigate directly to the first or last item:
2. Sorting and Filtering
In web search, it is common for results to be ordered by relevance to the query. But in other environments, such as online retail, a variety of other sort orders may be possible. These may vary from universal attributes such as price, customer rating or delivery date, to category-specific attributes such as release date for audio content, or publication date for books, and so on. Sort options such as these are commonly implemented using a drop down control, which allows the user to alternate between different sort keys:
For some types of highly attributed content it is possible to present the results in a manner that renders the sorting options even more apparent and invites greater interaction. At automotive classified site Carzone, for example, search results can be sorted by year, mileage, engine (size), price, etc.
This is achieved using a tabular panel, in which the column headers can be selected to choose a sort key and toggle the direction (ascending or descending). Likewise, searching the iTunes desktop app produces a heterogeneous, blended results page, but songs are rendered in their own tabular panel to allow sorting along the dimensions of album, artist, time, popularity, etc.
However, sorting using column headers has a number of shortcomings. For example, the sort direction is not always immediately apparent, and may not default to the most common use case. In addition, sorting by attributes not displayed becomes impossible, and common retail use cases such as sorting by popularity or bestselling become problematic since their corresponding column would be unlikely to contain anything particularly useful in each of the table cells (Nudelman, 2011).
Note also that not all attributes are equally meaningful as sort keys. For example, the sequence generated when sorting by a nominal attribute such as name or description is not inherently meaningful in the same way as sorting by a quantitative attribute such as mileage or price (Hearst, 2009). However, the alphabetical ordering does support other common use cases, such as scanning the list to find a particular model name.
In addition to sorting, most online retailers also offer options for filtering results. In principle, sorting and filtering are quite different operations, in the sense that sorting changes the display order of the results, whereas filtering actually removes items from that set. But in practice, to many users – particularly those with low technical expertise – they are practically indistinguishable. This is partially due to use of an inappropriate mental model, but is also an emergent property of the interaction: since many users do not explore beyond the first page of results, sorting controls act like a de facto filter, in the sense that they remove items from the immediate view.
A kind of hybrid example of sorting and filtering (and pagination) can be seen at the iPhone App Store. Here, content is grouped into various default categories to facilitate browsing along various popular dimensions (such as ‘Top Paid, ‘Top Free’, etc.). Selecting the appropriate category presents the results filtered by that category (e.g. ‘Top Paid’ filters out any free apps), but also presents them with an associated sort order. However, in some cases the sort key is an independent attribute (e.g. Top Paid filters by category but sorts by popularity), whereas in some cases the category serves both functions (Top Grossing both filters and sorts by revenue):
A more mainstream use of filtering is to allow users to refine their results by one or more independent dimensions or facets. This approach, known as faceted search, has become the dominant paradigm among online retail and many other commercial search applications. We’ve looked at faceted search in more detail in previous posts, exploring fundamentals such as layout and display along with more advanced topics such as wayfinding techniques and interaction models.
3. Query clarification
Earlier we looked at search result diversity, and explored the ways in which this can be used to communicate the alternative meanings for vague and ambiguous queries. A query such as ‘apple’, for example, might return results relevant to the company or the fruit. By including these alternative meanings as part of the first results page, we invite users to explore the subtleties of their information need and help them to build their own mental map of the information landscape.
But sometimes it is appropriate to resolve the ambiguity in a more direct manner. In online retail, for example, it is in everybody’s interest to help the user define their query more precisely, so that products offered more closely match their needs and intentions. A query for ‘MP3’ might return results for players, accessories, or indeed content, but until their real intention is established, the dialogue remains something of a guessing game. Instead, we should first invite the user to clarify their intent (Tunkelang, 2009).
There are a number of approaches to query clarification. One of the most common is to display the alternative interpretations in the form of matching categories, and invite the user to choose a more precise category for their information need. Amazon, for example, does this is a quite subtle manner. A query here for ‘mp3’ returns several million results, including players, accessories and content on the first page (along with best bets such as a promotion for the Amazon MP3 store and featured results for the Electronics Store). However, the primary navigation option in the left hand menu is a category selector:
In addition, the user is invited to choose a department (category) to enable sorting. Once a category is selected, facets specific to that category can then be offered in the left hand menu (e.g. storage capacity and features for an MP3 player, genre for a music download, and so on).
A more conspicuous variant could be seen at electrical retailer Comet. As expected, an ambiguous query here such as ‘washer’ returns a mixed set of results. However, this time the category selector is displayed much more prominently, directly above the search results. Both show the number of results returned, but Comet fails to display the current query in editable form (breaking the principle we discussed earlier):
A more direct approach such as this is more likely to solicit an early clarification, but at the expense of pushing ‘genuine’ products further down the page. Clearly, there is a balance to be found here: even an innocuous query such as ‘fridge’ can generate a category selector that extends over 20 lines in height, occupying almost all the visible screen space (before scrolling).
Indeed, the difference in approach is also reflected in their respective mobile sites: Amazon focuses on the search results, with a relatively unobtrusive invitation to select a category (from the departments listed at the foot of the page), whereas Comet focuses on category selection:
A more immersive approach can be seen at online retailer Littlewoods. Here, the category selector occupies the whole result page, showing examples from each category as separate groups. These groups include an invitation to view the complete set, e.g. “View all 69 results in Electricals”. The selector is also supported by a faceted menu on the left which displays the category headings as menu items:
But presenting a category selector isn’t the only way to support query clarification. For certain popular queries, it may be possible to adopt a ‘best bets’ approach that defaults instead to the most likely category. For example, a query for ‘washer’ at online retailer Debenhams returns a custom landing page specifically for kitchen appliances. Although the precise query context is missing from this page, further clarification is still possible by selecting a sub-category from the faceted menu on the left:
Of course, all the above approaches are ways of encouraging a user to clarify their intent after the query has been entered. But we shouldn’t forget the techniques we can apply before we even get to that point. As we saw earlier, as-you-type suggestions can make a profound difference to the process of query (re)formulation, correcting spelling mistakes and offering suggestions that the user might not have otherwise considered.
And once the query has been entered, related searches provide an additional indication of diversity, offering a starting point for further query clarification (such as ‘mp3 downloads’ vs. ‘mp3 player’ in the example above). And of course the facets themselves represent a conceptual map of the information landscape, showing areas of abundance and inviting further productive exploration and discovery. Each of these plays a part in the information journey, facilitating the user’s progress from a vague or ambiguous query to the satisfaction of their information need.
4. Comparing
As we saw earlier, there is a tension in the design of search result snippets: too detailed and they waste screen space; too brief and they induce pogo-sticking. Clearly, a balance needs to be found. But the optimal level of detail is not a static concept. Instead, it depends on the context; in particular, the user’s search mode.
In the early stages of the information journey, the user’s primary concern is on formulating effective queries and developing an initial overview of the results. This stage is characterised by search modes such as locating and exploring, and snippets play a vital role in helping the user identify promising items worthy of further examination. But once those candidates have been identified a different pattern of behaviour emerges, where the focus is less on exploring, and more on analysing and comparing individual items. These search modes are fundamental to online retail, where users need to identify the best option from many available. In this context, a different type of view is needed.
A common approach is to provide access to what is popularly known as a comparison view. Computing equipment retailer Dabs, for example, provides a column of checkboxes next to each search result, which marks items for comparison:
Selecting a “Compare” button at the head of the column the opens a separate view, which shows the full detail of each item in a separate column, enabling easy comparison of the individual product attributes:
However, this view also indicates that the user has inadvertently exceeded the maximum number of items that can be shown in the comparison view. A better approach is to avoid possibility at the outset. Online retailer Best Buy, for example, shows both the size limit and the current state of the comparison view using a dynamically updating preview:
The key goal of the comparison page is, of course, to facilitate analysing and comparing individual products. Best Buy offers further support for these search modes by organising the attributes within logical groups and providing an option to automatically highlight the differences between products:
Electrical retailer Comet also provides a comparison preview function using a pop up ‘item tray’ attached to the foot of the page. However, their comparison page opens as a dialog overlay within the context of the search results page, eliminating the disruptive effect of a page reload (and observing the design principle to ‘stay on the page’ (Scott and Neill, 2009)). Comet, with its strong emphasis on query clarification through category selection, also maintains independent comparison lists for each of its major product categories. This prevents the somewhat nonsensical scenario of a user inadvertently trying to compare completely unrelated items (such as toasters and televisions).
5. Summary and best practices
Search results pages play a key role in all stages of the information journey. At the outset, they can guide the user in clarifying the query and their broader information needs. Pagination, sorting and filtering then provide the means to explore the results to find promising directions. And in the latter stages, comparison views can support the detailed examination of individual items.
Pagination
- Communicate the range of pages using large target areas and a hover effect where appropriate
- Identify the current page, and provide Previous and Next links
- Consider infinite scroll approaches where contextually appropriate, e.g. mobile
- Where appropriate (e.g. for limited collections), provide First and Last links on the outside
- Allow users to change the default pagination setting (number of results per page)
Sorting and Filtering
- Provide sorting options that are specific to the category of results
- Consider offering a tabular style where sorting is likely to be a common use case (e.g. for highly attributed data)
- Note that this approach may not be suitable for certain retail use cases such as sorting by popularity
- Sorting and filtering are often misunderstood by users, particularly those with low technical expertise. Sorting can be seen as having the effect of filtering in that it removes items from the immediate view
Query clarification
- Provide support to clarify vague or ambiguous queries early in the information journey
- If using a category selector, choose a location and configuration that reflects its importance in the dialogue and ensure that it scales appropriately for highly ambiguous queries and across platforms
- Consider a ‘best bets’ approach for certain popular queries
Comparing
- Communicate the maximum size the comparison view, and provide a dynamic preview where possible
- Allow users to highlight the differences between rows in the comparison view
- Maintains independent comparison lists for the major result categories
References
- Marti Hearst (2009) Search User Interfaces. Cambridge University Press
- Greg Nudelman (2011) Designing Search: UX Strategies for eCommerce Success. Wiley
- Bill Scott and Theresa Neil, 2009. Designing Web Interfaces: Principles and Patterns for Rich Interactions. O’Reilly Media.
- Daniel Tunkelang, 2009. Faceted Search. Morgan Claypool.



















“Maintains independent comparison lists for the major result categories” is a rough one. The problem is that in a hierarchy, you have inheritance. And without taking that into account, you can break in a nasty way. They’ll lose their compare by drilling. You can try using the root nodes, but ultimately which level depends on how deep your tree is, and that too can vary.
You’ll meet a similar problem with keyword search. Unless you aggressively map keyword queries to categories (and filtered categories) — which is another potentially dangerous task — you’ll also lose this capability as well. One might suggest treating the keyphrase like a category, but users will modify the query if the faceted search does not have the filter they want.
As a reasonable heuristic, one can assert that x% of the words are the same before ‘resetting’ compare. You can also just assume all searches are the category ‘search.’
I wish I could see Comet to see if they’ve done any of this, but the company has “ceased trading.”
At the end of the day, I don’t think it works for many tasks, and I’m not sure it should be considered a best practice unless your category tree is very flat.
Thoughts?
Note: one of the worst practices I’ve seen in comparison tools is assuming that one must only want to compare items on one page subject to 1 set of filters. You didn’t mention it — probably because it’s obvious — but you can’t count the amount of US retailers who didn’t notice on 2 hands and 2 feet.
[...] Designing Search (part 6): Manipulating results (Information Interaction) [...]
Hi Jaimie: yes it a shame Comet bombed – how very unsporting of them. They could have at least waited till I’d published the article
Re the heuristic you mention, the comparison is (or was) only triggered when the user selects a specific product, which is already categorised to a unique location in the taxonomy. Hence they can maintain separate lists (for each branch). So they just decide at what level of the taxonomy it makes sense to conseider products as belonging to a common family, and then provide separate buffers within each which the user can fill to the max. Filtering or adding keywords doesn’t affect the buffer/list, only explicit product selection.