Search zones are subsets of a web site that have been indexed separately from the rest of the site’s content. When a user searches a search zone, he has, through interaction with the site, already identified himself as interested in that particular information. Ideally, the search zones in a site correspond to his specific needs, and the result is improved retrieval performance. By eliminating content that is irrelevant to his need, the user should retrieve fewer, more relevant, results.

On Dell’s site (Figure 8-2), users can select search zones by audience type: home/home office, small business, and so on. (Note that “all” is the default setting.) These divisions quite possibly mirror how the company is organized, and perhaps each is stored in a separate filesystem or on its own server. If that’s the case, the search zones are already in place, leveraging the way the files are logically and perhaps physically stored.

Figure 8-2. Two types of search zones: audience zones (top) and topical zones (bottom)

Additionally, users can select one or more of the site’s categories or subcategories. It’s probable that these pages come from the audience subsites, and that Dell allows its documents to be recombined into new search zones by indexing them by the keywords these zones represent. It’s expensive to index specific content, especially manually, but one of the benefits of doing so is flexible search-zone creation: each category can be its own search zone or can be combined into a larger search zone.

You can create search zones in as many ways as you can physically segregate documents or logically tag them. Your decisions in selecting your site’s organization schemes often help you determine search zones as well. So our old friends from Chapter 6 can also be the basis of search zones:

And so on. Like browsing systems, search zones allow a large body of content to be sliced and diced in useful new ways, providing users with multiple “views” of the site and its content. But, naturally, search zones are a double-edged sword. Narrowing one’s search through search zones can improve results, but interacting with them adds a layer of complexity. So be careful: many users will ignore search zones when they begin their search, opting to enter a simple search against the index of the entire site. So users might not bother with your meticulously created search zones until they’re taking their second pass at a search, via an Advanced Search interface.

Following are a few ways to slice and dice.

Indexing by topic

Ameriprise Financial employs loosely topical search zones with its site. For example, if you’re looking for information on investments that will help you achieve a financially secure retirement, you might preselect the “Individual” search zone, as shown in Figure 8-3.

Figure 8-3. Executing a search against the “Individual” search zone

The 85 results retrieved may sound like a lot, but if you’d searched the entire site, the total would have been 580 results, many dealing with topic areas that aren’t germaine to personal retirement investing.

Indexing recent content

Chronologically organized content allows for perhaps the easiest implementation of search zones. (Not surprisingly, it’s probably the most common example of search zones.) Because dated materials aren’t generally ambiguous and date information is typically easy to come by, creating search zones by date—even ad hoc zones—is straightforward.

The advanced search interface of the New York Times provides a useful illustration of filtering by date range (Figure 8-4).

Figure 8-4. There are many ways to narrow your New York Times search by date

Regular users can return to the site and check up on the news using one of a number of chronological search zones (e.g., today’s news, past week, past 30 days, past 90 days, past year, and since 1996). Additionally, users who are looking for news within a particular date range or on a specific date can essentially generate an ad hoc search zone.

Just as it’s often useful to provide access to subsets of your site’s content, it’s valuable to allow users to search specific components of your documents. By doing so, you’ll enable users to retrieve more specific, precise results. And if your documents have administrative or other content components that aren’t especially meaningful to users, these can be excluded from the search.

In the article from Salon shown in Figure 8-5, there are more content components than meet the eye. There is a title, an author name, a description, images, links, and some attributes (such as keywords) that are invisible to users. There are also content components that we don’t want to search, such as the full list of categories in the upper left. These could confuse a user’s search results; for example, if the full text of the document was indexed for searching, searches for “comics” would retrieve this article about finding a translator in Egypt. (A great by-product of the advent of content management systems and logical markup languages like XML is that it’s now much easier to leave out content that shouldn’t be indexed, like navigation options, advertisements, disclaimers, and other stuff that might show up in document headers and footers.)

Figure 8-5. This article is jam-packed with various content components, some visible and some not

Salon’s search system allows users to take advantage of the site’s structure, supporting searches by the following content components:

Would users bother to search by any of these components? In Salon’s case, we could determine this by reviewing search-query logs. But what about in the case of a search system that hadn’t yet been implemented? Prior to designing a search system, could we know that users would take advantage of this specialized functionality?

This question leads to a difficult paradox: even if users would benefit from such souped-up search functionality, they likely won’t ever ask for it during initial user research. Typically users don’t have much understanding of the intricacies and capabilities of search systems. Developing use cases and scenarios might unearth some reasons to support this level of detailed search functionality, but it might be better to instead examine other search interfaces that your site’s users find valuable, and determine whether to provide a similar type of functionality.

There is another reason to exploit a document’s structure. Content components aren’t useful only for enabling more precise searches; they can also make the format of search results much more meaningful. In Figure 8-6, Salon’s search results include category and document titles (“Salon Travel | In other words”), description (“The scoop on finding a translator in Egypt...”), and URL. Indexing numerous content components for retrieval provides added flexibility in how you design search results. (See the later section “Presenting Results.”)

Figure 8-6. Title, description, and URL are content components displayed for each result

Most retrieval algorithms employ pattern matching; that is, they compare the user’s query with an index of, typically, the full texts of your site’s documents, looking for the same string of text. When a matching string is found, the source document is added to the retrieval set. So a user types the textual query “electric guitar,” and documents that include the text string “electric guitar” are retrieved. It all sounds quite simple. But this matching process can work in many different ways to produce different results.

When you already have a “good” document on hand, some algorithms will convert that document into the equivalent of a query (this approach is typically known as document similarity). “Stop words,” like “the,” “is,” and “he” are stripped out of the good document, leaving a useful set of semantically rich terms that, ideally, represent the document well. These terms are then converted into a query that should retrieve similar results. An alternative approach is to present results that have been indexed with similar metadata. In Figure 8-7, the first of WebMD’s results for a search on “West Nile” is complemented by a link to “See More Content like this.”

Figure 8-7. Many WebMD search results are accompanied by a link to”See More Content like this”

Approaches such as collaborative filtering and citation searching go even further to help expand results from a single relevant document. In the following example from CiteSeer (see Figure 8-8), we’ve identified an article that we like: “Application Fault Level Tolerance in Heterogeneous Networks of Workstations.” Research Index automatically finds documents in a number of ways.

Figure 8-8. CiteSeer provides multiple ways to expand from a single search result

There are other retrieval algorithms, more than we can cover here. What’s most important is to remember that the main purpose of these algorithms is to identify the best pool of documents to be presented as search results. But “best” is subjective, and you’ll need to have a good grasp of what users hope to find when they’re searching your site. Once you have a sense of what they wish to retrieve, begin your quest for a search tool with a retrieval algorithm that might address your users’ information needs.

A very simple guideline is to display less information to users who know what they’re looking for, and more information to users who aren’t sure what they want. A variant on that approach is to show users who are clear on what they’re looking for only representational content components, such as a title or author, to help them quickly distinguish the result they’re seeking. Users who aren’t as certain of what they’re looking for will benefit from descriptive content components such as a summary, part of an abstract, or keywords to get a sense of what their search results are about. You can also provide users some choice of what to display; again, consider your users’ most common information needs before setting a default. Figures 8-9 and 8-10 show a site that provides both options to users.

Figure 8-9. Salon uses search results with summaries to help users who want to learn about the documents they’ve retrieved

Figure 8-10. and without summaries for users who have a better sense of what they need

When it’s hard to distinguish retrieved documents because of a commonly displayed field (such as the title), show more information, such as a page number, to help the user differentiate between results.

Another take on the same concept is shown in Figure 8-11, which displays three versions of the same book. Some of the distinctions are meaningful; you’ll want to know which library has a copy available. Some aren’t so helpful; you might not care who the publisher is.

Figure 8-11. Content components help distinguish three versions of the same book

How much information to display per result is also a function of how large a typical result set is. Perhaps your site is fairly small, or most users’ queries are so specific that they retrieve only a small number of results. If you think that users would like more information in such cases, then it may be worth displaying more content components per result. But keep in mind that regardless of how many ways you indicate that there are more results than fit on one screen, many (if not most) users will never venture past that first screen. So don’t go overboard with providing lots of content per result, as the first few results may obscure the rest of the retrieval.

Which content components you display for each result also depends on which components are available in each document (i.e., how your content is structured) and on how the content will be used. Users of phone directories, for example, want phone numbers first and foremost. So it makes sense to show them the information from the phone number field in the result itself, as opposed to forcing them to click through to another document to find this information (see Figure 8-12).

Figure 8-12. A yellow pages search doesn’t force us to click through for a phone number

If you don’t have much structure to draw from or if your engine is searching full text, showing the query terms within the “context” of the document’s text is a useful variation on this theme (see Figure 8-13). In this example, E*Trade displays the query terms in bold—an excellent practice, as it helps the user quickly scan the results page for the relevant part of each result. E*Trade further augments this useful context by highlighting the surrounding sentence.

Figure 8-13. e*Trade bolds the search query, and highlights its surrounding sentence to show its context

How many documents are displayed depends mostly on two factors. If your engine is configured to display a lot of information for each retrieved document, you’ll want to consider having a smaller retrieval set, and vice versa. Additionally, a user’s monitor resolution, connectivity speed, and browser settings will affect the number of results that can be displayed effectively. It may be safest to err toward simplicity—by showing a small number of results—while providing a variety of settings that the user can select based on his own needs.

We do suggest that you let users know the total number of retrieved documents so they have a sense of how many documents remain as they sift through search results. Also consider providing a results navigation system to help them move through their results. In Figure 8-14, ICON Advisers provides such a navigation system, displaying the total number of results and enabling users to move through the result set 10 at a time.

Figure 8-14. ICON Advisers allows you to jump ahead through screens of ten results at a time

In many cases, the moment a user is confronted by a large result set is the moment he decides the number of results is too large. This is a golden opportunity to provide the user with the option of revising and narrowing his search. ICON Advisers could achieve this quite simply by repeating the query “retirement” in the search box in the upper right.

Now that you have a group of search results and a sense of which content components you wish to display for each, in what order should these results be listed? Again, much of the answer depends upon what kind of information needs your users start with, what sort of results they are hoping to receive, and how they would like to use the results.

There are two common methods for listing retrieval results: sorting and ranking. Retrieval results can be sorted chronologically by date, or alphabetically by any number of content component types (e.g., by title, by author, or by department). They can also be ranked by a retrieval algorithm (e.g., by relevance or popularity).

Sorting is especially helpful to users who are looking to make a decision or take an action. For example, users who are comparing a list of products might want to sort by price or another feature to help them make their choice. Any content component can be used for sorting, but it’s sensible to provide users with the option to sort on components that will actually help them accomplish tasks. Which ones are task-oriented and which aren’t, of course, depends upon each unique situation.

Ranking is more useful when there is a need to understand information or learn something. Ranking is typically used to describe retrieved documents’ relevance, from most to least. Users look to learn from those documents that are most relevant. Of course, as we shall see, relevance is relative, and you should choose relevance ranking approaches carefully. Users will generally assume that the top few results are best.

The following sections provide examples of both sorting and ranking, as well as some ideas on what might make the most sense for your users.

Sorting by alphabet

Just about any content component can be sorted alphabetically (see Figure 8-15). Alphabetical sorts are a good general-purpose sorting approach—especially when sorting names—and in any case, it’s a good bet that most users are familiar with the order of the alphabet! It works best to omit initial articles such as “a” and “the” from the sort order (certain search engines provide this option); users are more likely to look for “The Naked Bungee Jumping Guide” under “N” rather than “T.”

Figure 8-15. Baseball-Reference.com displays search results in alphabetical order

Sorting by chronology

If your content (or your user) is time-sensitive, chronological sorts are a useful approach. And you can often draw from a filesystem’s built-in dating if you have no other sources of date information.

If your site provides access to press releases or other news-oriented information, sorting by reverse chronological order makes good sense (see Figures 8-16 and 8-17). Chronological order is less common and can be useful for presenting historical data.

Figure 8-16. The Washington Post’s default list ordering is by reverse-chronological order

Figure 8-17. as is Digg’s

Ranking by relevance

Relevance-ranking algorithms (there are many flavors) are typically determined by one or more of the following:

• How many of the query’s terms occur in the retrieved document

• How frequently those terms occur in that document

• How close together those terms occur (e.g., are they adjacent, in the same sentence, or in the same paragraph?)

• Where the terms occur (e.g., a document with the query term in its title may be more relevant than one with the query term in its body)

• The popularity of the document where the query terms appear (e.g., is it linked to frequently, and are the sources of its links themselves popular?)

Different relevance-ranking approaches make sense for different types of content, but with most search engines, the content you’re searching is apples and oranges. So, for example, Document A might be ranked higher than Document B, but Document B is definitely more relevant. Why? Because while Document B is a bibliographic citation to a really relevant work, Document A is a long document that just happens to contain many instances of the terms in the search query. So the more heterogeneous your documents are, the more careful you’ll need to be with relevance ranking.

Indexing by humans is another means of establishing relevance. Keyword and descriptor fields can be searched, leveraging the value judgments of human indexers. For example, manually selected recommendations—popularly known as “Best Bets”—can be returned as relevant results. In Figure 8-18, the first set of results was associated with the query “monty python” in advance.

Figure 8-18. A search of the BBC site retrieves a set of manually tagged documents as well as automatic results; the recommendations are called “Best Links” rather than “Best Bets” to avoid gambling connotations

Requiring an investment of human expertise and time, the Best Bets approach isn’t trivial to implement and therefore isn’t necessarily suitable to be developed for each and every user query. Instead, recommendations are typically used for the most common queries (as determined by search-log analysis) and combined with automatically generated search results.

There are other concerns with relevance ranking. It’s tempting to display relevance scores alongside results; after all, those scores are what’s behind the order of the results. In Figure 8-19, we searched for “storage” at Computer Associates’ web site.

Figure 8-19. What do these relevance scores really mean?

The first result does seem quite promising. But what exactly is the difference between a document with a relevance score of 50 percent and one with 49 percent? They are scored similarly, but the top result is CA’s events calendar—which covers CA events. Interestingly, the events calendar doesn’t even mention “storage.” Other results are a bit more relevant, but this is an excellent illustration of how relevancy algorithms do strange and complicated things behind the scenes. We don’t really know why the results are ranked this way. Showing scores only aggravates that sense of ignorance, so these should be used with caution; leaving out scores altogether is often a better approach.

Ranking by users’ or experts’ ratings

In an increasing number of situations, users are willing to rate the value of information. User ratings can be used as the basis of retrieval result ordering. In the case of Digg (see Figure 8-20), these ratings—based on Digg users’ votes on the pages submitted by other Digg users—are integral to helping users judge the value of an item, and form the foundation of an entire information economy. Of course, Digg has a lot of users who don’t shrink from expressing their opinions, so there is a rich collection of judgments to draw on for ranking.

Figure 8-20. User ratings fuel the ranking of these Digg results

Most sites don’t have a sufficient volume of motivated users to employ valuable user ratings. However, if you have the opportunity to use it, it can be helpful to display user ratings with a document, if not as part of a presentation algorithm.

Ranking by pay-for-placement

As banner-ad sales are no longer the most viable economic model, pay-for-placement (PFP) is becoming increasingly common to web-wide searching. Different sites bid for the right to be ranked high, or higher, on users’ result lists. Yahoo! Search Marketing (Figure 8-21) is one of the most popular sites to take this approach.

Figure 8-21. Overture (now Yahoo! Search Marketing) used to auction the right to be ranked highly

If your site aggregates content from a number of different vendors, you might consider implementing PFP to present search results. Or if users are shopping, they might appreciate this approach—with the assumption that the most stable, successful sites are the ones that can afford the highest placement. This is somewhat like selecting the plumber with the largest advertisement in the yellow pages to fix your toilet.

Despite all the ways we can list results, no single approach is perfect. Hybrid approaches like Google’s show a lot of promise, but you typically need to be in the business of creating search engines to have this level of involvement with a tool. In any case, our sites are typically getting larger, not smaller. Search result sets will accordingly get larger as well, and so will the probability that those ideal results will be buried far beyond the point where users give up looking.

However, one alternative approach to sorting and ranking holds promise: clustering retrieved results by some common aspect. An excellent study^[2] by researchers at Microsoft and the University of California at Berkeley show improved performance when results are clustered by category as well as by a ranked list. How can we cluster results? The obvious ways are, unfortunately, the least useful: we can use existing metadata, like document type (e.g., .doc, .pdf) and file creation/modification date, to allow us to divide search results into clusters. Much more useful are clusters derived from manually applied metadata, like topic, audience, language and product family. Unfortunately, approaches based on manual effort can be prohibitively expensive.

Some automated tools are getting better at approximating the more useful topical types of clustering that often serve users best. In Figures 8-22 and 8-23, Clusty and WiseNut contextualize the query “RFID” with such topics as “Privacy,” “Barcode,” and “RFID implementation.”

Figure 8-22. Clusty contextualizes search results for the query “RFID”

Figure 8-23. as does WiseNut; the positioning of related categories differs, as do the categories generated by both services

These clusters provide context for search results; by selecting the category that seems to fit your interest best, you’re working with a significantly smaller retrieval set and (ideally) a set of documents that come from the same topical domain. This approach is much like generating search zones on the fly.

You’ve provided users with a set of search results. What happens next? Certainly, they could continue to search, revising their query and their idea of what they’re looking for along the way. Or, heavens, they might have found what they’re looking for and are ready to move on. Contextual inquiry and task-analysis techniques will help you understand what users might want to do with their results. The following sections discuss a few common options.

Printing, emailing, or saving results

The user has finally reached his destination. He could bookmark the result, but he likely doesn’t want to return to this document where it lives on the site. Instead, he wants to grab it and take it with him.

Obviously he can print it, but not all documents are designed to be printed—they may sport banner ads or be crowded with navigational options. If many of your users wish to print and your content isn’t print-friendly, consider offering a “print this document” option that provides a clearer, more printable version of the document. Alternatively, users may want a digital version of the file. And as so many of us use our email programs as personal information managers, providing an “email this document” function can come in handy as well. Both functions are shown in Figure 8-24.

Figure 8-24. New York Times articles can be formatted for printing or emailed for later use

The New York Times also allows users to save articles for future retrieval. We wonder if many users take advantage of “Save,” as most users rely on bookmarking options that aren’t specific to a single site. The Times also provides a “reprints” option and enables users to toggle between multiple- and single-page views of the article. For the most part, these options are conceived with a good understanding of what users might want to do next, now that they’ve found an article of interest.

Select a subset of results

Sometimes you want to take more than one document along with you. You want to “shop” for documents just like you shop for books at Amazon. And if you’re sorting through dozens or hundreds of results, you may need a way to mark the documents you like so you don’t forget or lose track of them.

A shopping-cart feature can be quite useful in search-intensive environments such as a library catalog. In Figures 8-25 and 8-26, users can “save” a subset of their retrieval and then manipulate them in a “shopping basket” once they’re done searching.

Figure 8-25. The Ann Arbor District Library catalog enables users to select a few records to “save”

Figure 8-26. and email the results or download them to a local disk

Save a search

In some cases it’s the search itself, not the results, that you’re interested in “keeping.” Saved searches are especially useful in dynamic domains that you’d like to track over time; you can manually re-execute a saved search on a regular basis, or schedule that query to automatically be rerun regularly. Some search tools, like that of Science Magazine’s ScienceNOW service, allow both, as shown in Figure 8-27.

Figure 8-27. Queries can be saved for future use and scheduled to be automatically re-executed on a regular basis

As search results become more “portable”—allowing users to access them without visiting the originating search system’s site—they can be syndicated using RSS or Atom. For example, you can save and automatically re-execute a search in Google using the Google Alerts service, shown in Figure 8-28, and the results of your saved query can be monitored via an RSS or Atom feed (as well as by email).

Figure 8-28. Monitoring queries using Google Alerts; results can be delivered via RSS or Atom feeds, as well as email

Your site is likely to have the ubiquitous search box, as shown in Figure 8-29.

Figure 8-29. The ubiquitous search box (in this case, from ibm.com)

Simple and clear. Type in some keywords (“directions Somers”) or a natural language expression (“What are the directions to the Somers offices?”), hit the “search” button, and the whole site will be searched and results are displayed.

Users make assumptions about how search interfaces work, and you may want to test for those as you design your own search system. Some common user assumptions include:

If your users have those assumptions and are not especially motivated to learn more about how your site’s search works differently, then go with the flow. Give them the box. You certainly could provide a “help” page that explains how to create more advanced, precise queries, but users may rarely visit this page.

Instead, look for opportunities to educate users when they’re ready to learn. The best time to do this is after the initial search has been executed and the user reaches a point of indecision or frustration. The initial hope that the first try would retrieve exactly what they were looking for has now faded. And when users are ready to revise their searches, they’ll want to know how they can make those revisions. For example, if you search IBM’s site for “servers” (see Figure 8-30), you’ll likely get a few more results than you’d like.

Figure 8-30. IBM’s search results provide ample opportunities to revise your search

At this point, IBM’s search system goes beyond the box: it tells the user something to the effect of “Here are those 729,288 results that you asked for. Perhaps this is too many? If that’s the case, consider revising your search using our souped-up ‘advanced search’ interface, which allows you to narrow your search, as shown in Figure 8-31. Or learn how to search our site better from our ‘tips’ page.” Or, select from a list of categories (really search zones) to narrow your results further.

Figure 8-31. including the ability to narrow by category

In general, too many or too few (typically zero) search results are both good indicators for users to revise their searches; we’ll cover more on this topic in the section “Supporting Revision” later in this chapter.

The box can cause confusion when it occurs alongside other boxes. Figure 8-32 shows a main page with many boxes, all of which come with the same “go” button, regardless of functionality. It’s a good bet that users won’t read the nice labels next to each box and will instead do all sorts of confounding things, like typing their search queries in the “password” box, not to mention URLs in the “search” box. (Search logs regularly turn up such “box bloopers.”)

Figure 8-32. Where will users type in their search queries?

A better approach is to place the search box nearer to the site-wide navigation system at the top of the page and relabel its “go” button as “search.” The other boxes could be made less prominent on the page or moved somewhere else altogether. Consistent placement of the search box alongside other site-wide navigation choices on every page in the site, along with the consistent use of a button labeled “search” that comes with that box, will go a long way toward ensuring that users at least know where to type their queries.

In Figure 8-33, the three search boxes could be reduced to one that searches a combined index of articles, comments, and users. This would save space and demand less of the user. The distinctions between the three types of search zones could always show up (and be made selectable) in a pull-down menu or advanced search interface.

Figure 8-33. These three boxes could be combined into one

Clearly, there are many assumptions behind that innocuous little search box, some made on the part of the user, and some by the information architect who decides what functionality will be hidden behind that box. Determining what your users’ assumptions are should drive the default settings that you set up when designing the simple search interface.

Advanced search interfaces are where much of the search system’s functionality is “unveiled” to users. In stark contrast to The Box, advanced search interfaces allow much more manipulation of the search system and are typically used by two types of users: advanced searchers (librarians, lawyers, doctoral students, medical researchers), and frustrated searchers who need to revise their initial search (often users who found that The Box didn’t meet their needs).

Often, you find everything and the kitchen sink thoughtlessly stuffed into advanced search interfaces. Fielded searching, date ranges, search-zone selection, and specialized query languages all crop up here. In fact, these can often crowd the interface and make it difficult for users to know what to do. Gartner’s advanced search interface, shown in Figure 8-34, for example, doesn’t even fit on one page.

Figure 8-34. Gartner’s endless advanced search interface: who will use it?

We won’t cover these functions in this chapter because we’ve found that, contrary to our original assumptions, few users ever take advantage of them. Therefore, because few users will ever visit your advanced search page, we don’t recommend investing much effort into its design. You’re better off looking for ways to enable users to revise when they need to—in other words, in the appropriate context. More on that below.

As for advanced search, it can’t be completely ignored, unfortunately. It is something of a convention, and many users will expect to see it. Perhaps a good rule of thumb is to unearth your search engine’s various heavy-duty search functions on the advanced page for those few users who want to have a go at them, but design your search system with the goal of making it unnecessary for the vast majority of searchers to ever need to go to the advanced search page.

We’ve touched on what can happen after the user finds what she’s looking for and the search is done. But all too often that’s not the case. Here are some guidelines to help the user hone her search (and hopefully learn a little bit about your site’s search system in the process).

Repeat search in results page

What was it I was looking for? Sometimes users are forgetful, especially after sifting through dozens of results. Displaying the initial search within the search box (as in Figure 8-35) can be quite useful: it restates the search that was just executed, and allows the user to modify it without re-entering it.

Figure 8-35. The original query is displayed on the results page and can be revised and re-executed

Explain where results come from

It’s useful to make clear what content was searched, especially if your search system supports multiple search zones (see Figure 8-36). This reminder can be handy if the user decides to broaden or narrow her search; more or fewer search zones can be used in a revised search.

Figure 8-36. Dell’s search system shows you where you searched (i.e., “Technical Support”), and makes it easy to reach results from other search zones

Explain what the user did

If the results of a search are not satisfactory, it can be useful to state what happened behind the scenes, providing the user with a better understanding of the situation and a jumping-off point should she wish to revise her search.

“What happened” can include the two guidelines just mentioned, as well as:

• Restate the query

• Describe what content was searched

• Describe any filters that might be in place (e.g., date ranges)

• Show implicit Boolean or other operators, such as a default AND

• Show other current settings, such as the sort order

• Mention the number of results retrieved

In Figure 8-37, the New York Times site provides an excellent example of explaining to the user what just happened.

Figure 8-37. All aspects of the search are restated as part of these search results

Integrate searching with browsing

A key theme in this book is the need to integrate searching and browsing (think of them together as “finding”), but we won’t belabor it here. Just remember to look for opportunities to connect your search and browse systems to allow users to easily jump back and forth.

In Figures 8-38 and 8-39, Amazon.com provides this functionality in both directions.

Figure 8-38. Searching leads to browsing: a search for “camera” retrieves categories as well as documents

Figure 8-39. while browsing leads to searching: navigate to the “Digital Cameras” section, and you’ll find the search box set to search that zone

You can strive to support iterative searching with fully integrated browsing and state-of-the-art retrieval and presentation algorithms, yet users still will fail time and time again. What should you do when presenting the user with zero results, or with way too many?

The latter case is a bit easier to address, because in most cases your search engine provides relevance ranked results. In effect, winnowing oversized result sets is a form of search revision, and often the user will self-select when he is ready to stop reviewing results. But it is still useful to provide some instruction on how to narrow search results, as shown in Figure 8-40.

Figure 8-40. Dell’s tech-support help page provides advice on how to deal with too many results

You can also help users narrow their results by allowing them to search within their current result set. In Figure 8-41, the initial search for “naked bungee jumping” retrieved over 9,000 documents; we can “search within these results” for “figure skating” to narrow our retrieval.

Figure 8-41. Exalead allows users to search within their result set

At the other end of the spectrum, zero hits is a bit more frustrating for users and challenging for information architects. We suggest you adopt a “no dead ends” policy to address this problem. “No dead ends” simply means that users always have another option, even if they’ve retrieved zero results. The options can consist of:

It’s worth noting that we’ve seen few (if any) search systems that meet all these criteria.