Search implementations often begin with the question: “What’s the best (or cheapest, or easiest-to-use) search engine? This quest for the One True Search Engine is, I think, misguided. Search engines are more alike than they are different. You plug in a search term, you get back a list of URLs. In this chapter, we’ll focus on the much neglected art of organizing that list of URLs in useful ways.
Webmasters who obsess about the design of their standard web pages often invest little or no effort in the design of their search-results pages. By design I don’t simply mean the kinds of template alterations that stamp a site-branded style onto the default Excite or Verity or Microsoft result pages. And I don’t mean just ordering results by relevance, which begs the question: relevant to whom and for what? Rather, I mean a deep reorganization of the result set, which both reflects and adapts to the underlying information architecture of one or more docbases. Search engines can’t do this for you. Most aren’t intrinsically programmable; those that are (such as the Microsoft Index Server) still can’t easily do the kinds of data wrangling required to get the job done well. And yet the task isn’t really hard at all, if you build docbases with an eye toward search integration and if you understand how web components work.