Hi there! Welcome to our blog. Don't forget to sign up for our free RSS feed. We Triple Dog Dare Ya! And thanks for visiting!

Building a custom search engine for a web-based application (particularly a CMS) can be a daunting experience the first time around. No matter what approach you take, what platform you’re using, or what kinds of users you have, you need to keep the Three Laws of Search Engine Usability in sight.

(With my apologies to Dr. Asimov)

Rule 1. The search engine must be fast.
Rule 2. The search engine results must be easily differentiated to the user–they need to be able to get to the information they need quickly.
Rule 3. Never do anything with Rule 2 that adversely affects Rule 1, or vice versa.

Rule #1 is pretty self-explanatory. If your search engine is slow to produce results, people won’t use it. Why would it be slow? Are you physically searching through text or HTML files or using xpath queries through XML to get what you need? Then use some kind of text-based index that is created every few hours by a cron job.

This index would essentially be a reverse dictionary. For every word found in your files (minus stop words like the/and/a/what/who/when/where/how etc) you would create a listing that would map word to each file it appears in, like this:

Lincoln index.html,presidents.html,lincolnbio.html
Washington index.html,presidents.html,washbio.html

Then your search engine could parse the index instead of all the files. The good news? This method is speedier. The bad news? Your index is only as up to date as the last time it was run. There may be a lag lasting many hours.

If you are using a database query and its slow, think about indexing your most frequently accessed tables. On mySQL and other database products, you can turn on query caching and store relevate information in RAM.

Rule #2 is a bit more subtle. Instead of returning a pile of search results, each of which undoubtly contain a link, you have to provide more context and information design elements to help users make sense of the information provided by the search engine.

For example, you may want to bold the link to the document in question. Good first step. You may also want to display meta keywords, meta description, or the page title as well. You will also likely want to number your search results and provide plenty of space before and after each item in the result list to boost visibility.

Rule #3 is even more subtle than Rule #1 or Rule #2. Let’s say you have a fairly fast search engine, and you decide to use an icon next to the link for each search result. You want users of the site to start asociating PDF downloads with an acrobat logo or press releases with another type of logo. Great idea!

Just don’t go overboard with #2 or you’ll start affecting #1. What do I mean? Let’s stick with the same explamble. Don’t use rollover effects on your image or an aimated image. Don’t use a very large image. Either one of these will add server load and processing time if the search result is long or complicated.

On the other hand, don’t just say, “We’re goin’ for speed!” and just dump out a bunch of links. The folks who want to use the search are doing it for one of just a few reasons:

* They are looking for a specific document
* They are looking for a particular class of documents (all the press releases from 2004)
* They are looking for documents that live in different regions of the site (all PPT presentations on Disaster Recovery regardless of whether they live under Products, Services, or Consulting).

Bookmark:

Tags: No Comments