In everyday life, human beings respond to new situations by making immediate categorical assumptions -- "judging a book by its cover" -- before delving into specifics. Although never true in all circumstances, these assumptions provide an excellent framework for later judgments, such as the generalizations below. Although there are clear exceptions, these assumptions are correct in more than 50% of ordinary circumstances.

Sometimes writers and editors want to classify a database record as more relevant or irrelevant than usual. Advertisers want their products to appear more relevant than competitors’, and authors might think explanations are more desirable than definitions. These opinions usually reveal themselves only after reviewing results to a few inadequate searches.

Writers can add editorial values to the records for the algorithm to consider. For example, note that text-based search engines cannot effectively rate graphics: important diagrams and maps often are ignored inadvertently. By individually "boosting" the ratings of graphics, authors can guarantee graphics better placement in the results list.

This approach also can be taken to an effective extreme, often called keywording or (unfortunately again) indexing.

Editorially chosen text, called keywords, is added into each database record. Then, the search algorithm considers only these keywords, and not the documentation itself. Further, the keywords can be collected into a standalone document and scanned by users, as a replacement for searching. This is how indexes are built for online help documentation. (When applied to entire web sites, this is known as meta tagging.) With careful keyword selection, a more accurate search is almost guaranteed. One interesting technique is adding commonly misspelled words as keywords so that errors and ignorance don’t interfere with a successful search.

Any case-by-case editorial interpretation of data is resource-intensive. In fact, the entire process is much more like book indexing than search programming.

Basic search algorithms attempt to find simple equalities: When does the search term match a term in a database record? Unfortunately, the human definition of "equality" is not limited to identical words. Users might be interested in any different word that has the same meaning, has a similar spelling, or shares the same linguistic root. Several algorithms can use rules of language and grammar to serve these needs.

For example, a user searching for "computer" might also want records that contain the word "computers." This can accomplished using a simple algorithm that looks for singulars as well as plurals. A more complicated grammatical algorithm known as stemming compares only linguistic roots: "Computer" is equivalent to "compute," "computation," and "computational."

A thesaurus identifies words that share meanings. For example, a search for "computer" finds examples of "desktops" and "laptops." Thesauri have to be built by human beings, and some can be purchased. Understanding the context and scope of the documentation is important. To many applications, equating "acetaminophen" with its many brand names is not relevant.

The algorithm can also interpret the user’s query before searching the database, such as testing for common misspellings. (This is the opposite approach to using misspellings as keywords, mentioned above.) The algorithm can ignore particularly unimportant words, called stop words (usually prepositions, conjunctions, and articles) that are too common to be limiting. If the user is allowed to use search-related syntax such as wildcards, quotation marks, and Boolean expressions, the algorithm must further interpret the query.

Search engines that accept natural language queries are an extreme case. These engines, which attempt to accept queries like "How can I print graphics upside-down?" and "How far is the Boston Aquarium from Faneuil Hall?" utilize years of grammatical and syntactical research and continue to improve. (In contrast, most humans perform this kind of full-sentence interpretation easily, automatically, and unconsciously!) To use natural language algorithms in documentation or on web sites, the only sensible option these days is to license the technology.

Algorithms also can process hits before displaying them to the user. Parental controls use this technique to repress content considered vulgar or otherwise inappropriate.

Query processing of any kind relieves the user from the burden of knowing how to search and what to search for.

Users are often interested in a particular word only when defined in a specific way or used in a specific context. For example, there are two meanings for the words "glasses" and "speakers." Because of this language-based subjectivity and ambiguity, computers are unable to guess which interpretation the user desires.

Instead of ignoring the ambiguity, the search engine can respond by asking for more information. For example, if a user searches for "glasses," the search algorithm gives the user a choice between "drinking glasses" and "eyeglasses." The response to this choice influences the final database search.

Iterative searching is a natural human process:

An interruptive model of searching accommodates this process. Unfortunately, most users are not interested in secondary choices and might think the engine is "showing off." Thus, it’s important to provide results in addition to providing these options. For example, users searching for "glasses" should be presented with results for this ambiguous search and the option to refine the search using either "drinking glasses" or "eyeglasses." (Also remember that there might be additional interpretations of the query words that cannot be predicted.)

There is also the opportunity to override the natural behavior of a search engine for specific queries. Sometimes there is an advantage to not performing the search, particularly when the user considers the search input box as the only viable input opportunity. If a user searches for the word "home," it might make sense to send the user to the home page of the site instead of displaying search results. Likewise, a user who types "lycos.com" in the search box is probably interested in navigating to the Lycos site.

After applying all this "intelligence" to your search engine, there is still one major element missing: context. Users often believe they are searching something different than what is really being searched:

• After one search, users might think they can search the search results.
• After navigating into a section of documentation, they might expect the search to be limited to that section.
• Users might suspect that a search engine on a web site actually searches the entire Web.

It is important to communicate the scope of the search. Instead of labeling the engine with only the word "Search," be more explicit: "Search our site" or "Search the Web." Consider allowing users to choose the scope with radio buttons or drop-down menus: "Search: This Site (or) This Section (or) This Page." In addition, if there are sections of a site that are password-protected or otherwise restricted, identify whether or not users can get search results for those sections without a password. The more flexibility you allow with search scope, the more search databases you need.