6.3. Designing the Search Interface
With so much variation among users to account for, there can be no single ideal search interface. Although the literature of information retrieval includes many studies of search interface design, many variables preclude the emergence of the right way to design search interfaces. Here are a few of the variables on the table:
We can, however, provide basic advice that you should consider when designing a search interface.
6.3.1. Support Different Modes of Searching
Before diving into design, think hard about why users are searching your site, and what they want to get out of their search. Are they likely to search for certain types of information, such as specific product descriptions or staff directory entries? If so, support modes of searching that are delineated by content types -- use the same interface to allow users to search the product catalog, or the staff directory, or other content areas (content-delineated indexing involves the creation of search zones, which we'll cover later in this chapter). Are non-English speakers important to your site? Then provide them with search interfaces in their native languages, including language-specific directions, search commands and operators, and help information. Does your site need to satisfy users with different levels of sophistication with online searching? Then consider making available both a basic search interface and an advanced one.
For example, one of our clients, UMI, sells dissertations to an audience that includes researchers, librarians, and others who have been using advanced online information systems for years. We needed an interface that would accommodate this important expert audience who were used to complex Boolean and proximity operators, and who were already very used to the arcane search languages of other commercial information services. However, a simple search interface was also required, because at times users wouldn't need all the firepower of an advanced search interface, especially when conducting simple, known-item searches. Additionally, because it had become available via the Web, a whole new audience of novices would encounter this product for the first time; we assumed that these newbies wouldn't be comfortable with a complex search interface.
Figure 6-1. Although we could have simplified this interface by foregoing the three radio button selections, they add utility and let users know what they are searching without taking up too much screen space.
So we created a simple interface that almost anyone could figure out and use right away, shown above in Figure 6-1. A simple search box is ideal for the novice or for a user with a pretty good sense of what he or she is looking for. (We made sure to provide a single search query box; our experience shows that most users don't care for separate boxes, one for each query term, divided by Boolean operators.) Minimal filtering options are provided, including searching for keywords within title and abstract fields, searching within the author field, or searching within the publication number field. These filtering options provide the user with more power by allowing more specific searching. But because the labels Keyword, Author, and Publication Number are fairly self-explanatory, they don't force the user to think too much about these options.
Figure 6-2. Because they present so much information, more complex search interfaces generally can't be embedded on other pages and instead require a dedicated page.
For the advanced users, a more powerful interface was created, shown above in Figure 6-2. This interface supports the following types of searching:
Because this advanced interface supports so many different types of searching, we provided a substantial help page to assist users. For users of common browsers, the help page shown in Figure 6-3 launches in a separate browser window so that users don't need to exit the search interface to get help.
Figure 6-3. This help page serves as a ready reference to help users take advantage of the searching capability offered by this search engine and offers examples. It launches in a separate browser window.
6.3.2. Searching and Browsing Systems Should Be Closely Integrated
As we mentioned earlier, users typically need to switch back and forth between searching and browsing. In fact, users often don't know if they need to search or browse in the first place. Therefore, these respective systems shouldn't live in isolation from one another.
When we redesigned the Argus Clearinghouse, we integrated these two elements on a single page called Search/Browse, shown in Figure 6-4. This combined interface to searching and browsing makes it clear to the user what he or she can do there. The search/browse approach can be extended by making search and browse options available on the search results page as well, especially on null results pages, when a user might be at a dead end and needs to be gently led back into the process of iterative searching and browsing before frustration sets in.
Figure 6-4. Because its vertical space requirements are relatively small, the simple search interface is located toward the top of the page. It is followed by a browsing scheme too long to be displayed in its entirety. But users get a sense of what they'll see if they scroll further.
6.3.3. Searching Should Conform to the Site's Look and Feel
Search engine interfaces, and more importantly, retrieval results, should look and behave like the rest of your site. This advice may seem painfully obvious, but because many search engines are packaged as ready-to-go add-ons to a site, site developers don't bother to customize them. For example, the interface and results produced by the Excite search engine are easy to detect. In fact, they look and work so similarly from site to site that it's easy to forget that they are actually parts of individual sites. Figure 6-5 is a great example of a search interface which hasn't been customized, while Figure 6-6 shows how the search interface can be integrated with the rest of the site's look and feel.
Figure 6-5. Search results from a search engine that hasn't been customized ...
Figure 6-6. ... and from one that has. In Figure 6-5, the search results use Excite's standard images, and look more like they're part of Excite's site than Chevron's. The Chrysler site's searching system's look and feel is much more closely integrated with the rest of the site.
6.3.4. Search Options Should Be Clear
We all pay lip service to the need for user documentation, but with searching, it's really a must. Because so many different variables are involved with searching, there are many opportunities for things to go wrong. On a Help or Documentation page, consider letting the user know the following:
6.3.5. Choose a Search Engine That Fits Users' Needs
At this point, you ideally will know something about the sorts of searching capabilities that your site's users will require (not to mention what your budget will allow!). So select a search engine that satisfies those needs as much as possible. For example, if you know that your site's users are already very familiar with a particular way of specifying a query, such as the use of Boolean operators, then the search engine you choose should also support using Boolean operators. Does the size of your site suggest that users will get huge retrieval results? Be sure that your engine supports techniques for whittling down retrieval sizes, such as the AND and NOT operators, or that it supports relevance-ranked results that list the most relevant results at the top. Will users have a problem with finding the right terms to use in their search queries? Consider building in a thesaurus capability (AltaVista's SearchWizard (http://altavista.digital.com/av/lt/help.html) is a common example) or synonym table so that a query for the term car may retrieve documents with the term automobile. As the market for search engines booms, more and more interesting options will be packaged with these tools; let your users' needs be the major factor that guides your choice.
6.3.6. Display Search Results Sensibly
The first factor is the degree of structure your content has. What will your search engine be able to display besides just the titles of retrieved documents? Is your site's content sufficiently structured so that the engine can parse out and display such information as an author, a date, an abstract, and so on?
The other factor is what your site's users really want. What sorts of information do they need and expect to be provided as they review search results?
When you are configuring the way your search engine displays results, you should consider these issues:
Figure 6-10. Lycos Pro's Java Power Panel allows users to determine which document characteristics are most relevant to their searches through adjusting their settings. Although it's not likely something you'll whip up in minutes for your own site, it is an interesting concept.
Many search engines use counterintuitive sorting approaches by default, including when the file was last updated or indexed (a variant of chronological ordering), or what physical directory the file resides in. Avoid these defaults; they are obtuse and will confuse the user. Whatever approach you use, make the ranking order clear to users by making the sort field a prominent part of each result. Consider shifting the decision on what sort is most useful by giving the user the option of selecting their own sorting option.
6.3.7. More About Relevance
Let's say you're interested in knowing what the New Jersey sales tax is. Maybe you're driving through on a trip, and want to know if you should stop at an outlet mall or wait until you get to Pennsylvania, where you know the sales tax. So you go to the State of New Jersey web site and search on sales tax (see Figure 6-11).
Figure 6-11. Results from the query "sales tax" in the State of New Jersey web site.
The 20 results are scored at either 84% or 82% relevant. Why does each document receive only one of two scores? Are the documents in each group so similar to each other? And what the heck makes a document 2% more relevant than another? Let's compare two retrieved documents, one which received an 84% relevancy score (Figure 6-12), the other 82% (Figure 6-13).
Figure 6-12. Sales & Use Tax: Business was scored at 84% relevancy...
Figure 6-13. ...and Sales & Use Tax: Individuals received an 82% relevancy ranking. Can you tell the difference?
As you can see, these documents are almost exactly the same. Both have very similar titles, and neither uses hidden <META> tags to prejudice the ranking algorithm. Finally, both documents mean essentially the same thing, differing only in that one deals with businesses and the other with individual consumers. The only apparent difference? While sales and tax appear within <TITLE> and <H1> tags of both documents, they appear in the body of only the first document, not in the second. The search engine probably adds 2% to the score of the first document for this reason. Probably, because, as the algorithm isn't explained, we don't know for sure if this is the correct explanation.
6.3.8. Always Provide the User with Feedback
When a user executes a search, he or she expects results. Usually, a query will retrieve at least one document, so the user's expectation is fulfilled. But sometimes a search retrieves zero results. Let the user know by creating a different results page specially for these cases. This page should make it painfully clear that nothing was retrieved, and give an explanation as to why, tips for improving retrieval results, and links to both the Help area and to a new search interface so the user can try again (see Figure 6-14).
Figure 6-14. Although no results were retrieved, the user is presented with other options, such as trying another search, reviewing the search tips, or switching to browse mode. These options dissuade users from giving up on finding information in the site.
6.3.9. Other Considerations
You might also consider including a few easy-to-implement but very useful things in your engine's search results:
Copyright © 2002 O'Reilly & Associates. All rights reserved.