in

ASP.NET Weblogs

This Blog

Syndication

Jason Salas' WebLog

On-air and online: making people laugh, making people think, pissing people off

Technical pet peeve: no search services are better than weak search services

The one thing that's really been irking me in using the web lately is poor search utilities.  And this is regardless of the platform the site was developed with.  Nothing get me more steamed these days than browsing to a content-rich site, looking for an article, code snippet, or other content and getting bad and unhelpful search results. 

On one such site today, I even copy-and-pasted the name of the article I was looking for into a textbox and searched for it to no avail - “Your search returned 0 results”.  Yecch.

This is the direct result of metasearch services like Google, Dogpile and AllTheWeb.com others taking off - people expect more from individual sites.  And they have every right to.  Those of us not at that level likely can't provide similar functionality as those tools, but we could at least allow a user to search our own content effectively.

Think about it: search facilities are functionally the easiest things a web developer can build, but realistically one of the most challenging – if not the hardest - things to do right and maintain on a content-rich site.

My point is that having weak search services - and services in general, for that matter - is poor customer service and therefore detrimental to your image (assuming you're concerned about that sort of thing).  And this is seen in major sites, from major companies, offering content that should be its nature be (1) indexed constantly (2) accessed by a powerful, flexible, intelligent search service.  This is a no-brainer, but why people on today's intelligent web continue to provide hard-to-use and even worse, poorly-performing search facilities amazes me. 

Having a simple SQL-based LIKE '%searchString%' statement doesn't cut the mustard these days.  You'll arrive with incredibly inflated recordsets and ill-formed results.  Steve Walther has what in my opinion is the best discussion on developing effective search tool in his classic “ASP.NET Unleashed“, showing how easy it us to use to use Full-Text Indexing, and SQL Server's FREETEXT and FREETEXTTABLE functions.  I'm not sure why more people haven't gravitated toward this end, weighing the gains against the efforts.

And I'm only ragging on those who've continued to have weak search capabilities, because I was there myself once. I used to run the Search utility that shipped with FrontPage several years ago to manage my site's content, but that got really old, really fast.  We now use a simple web form that outputs results off of Google, specific to our site, and we couple this with a database-driven Keyword Search utility based off of a web service we developed that works like those found on AOL or ESPN (we tease keywords to use throughout our broadcasts, so we have a bit more control over the ambiguity of our searches). 

It used to be written constantly in online marketing journals that the key to winning on the web is having a search utility.  I'd like to add a corollary - if you haven't got great search services, remove them altogether.  Better to be lacking such a feature and have a decent alibi than be sorely inferior with a justifiable motive.   Most people will use search engines anyway.

Published Feb 11 2004, 04:06 PM by guam-aspdev
Filed under: ,

Comments

 

TrackBack said:

February 11, 2004 4:37 AM
 

Wallym said:

Jason,

The reason that I see why they aren't using FreeText and such is that MS's fulltext engine in Sql2k is not very good. It takes an amazing effort on the part of the CPU to get it working. Yukon's full text engine is suppossed to be much improved.

Wally
February 11, 2004 5:46 AM
 

Derick Bailey said:

The actual indexing may take some cycles, but it only happens on the schedule that you set. Any good DBAmin should know how to setup the schedule to run during the lowest traffic times, and create a good fulltext index for searching.

As for the actual fulltext searching in SQL Server 2K, it's actually part of Indexing Service that gets called to do the searching. If someone complains about SQL 2K fulltext, but also uses the Indexing Service, then that person is full of crapp.

I personally think that the fulltext searching in SQL2K is quite nice. But then, I actually spent a few minutes to write a query parsing engine that builds proper fulltext search queries based on user input.
February 11, 2004 9:24 AM
 

TrackBack said:

February 11, 2004 10:53 AM
 

Jason Salas said:

Hi guys,

Good thoughts. I'm pondering moving to FTI myself, but in doing so I'll need to migrate the entire SQL Server DB we use now (only about 9,000 records, with multiple NTEXT fields) to a different database server.

Has anyone seen any creative alternatives to using a good classical search?
February 11, 2004 6:59 PM
 

Sassy said:

Fulltext searching on SQl2k is a pathetic joke. Not because of CPU cycles, because it _simply _dont _work. Once again, garbageware from Microsoft
June 23, 2004 6:33 PM
 

TrackBack said:

<p>Admittedly, I haven't used full text search on SQL 2000.<br />
But I am sure DBSight can beat it.</p>
<p>I have seen posts like this<br />
<a href="http://weblogs.asp.net/jasonsalas/archive/2004/02/11/71130.aspx">Technical pet peeve: no search services
April 14, 2005 11:56 AM

Leave a Comment

(required)  
(optional)
(required)  
Add