A Really Useful Search

Raven’s web-based administration and CRM module got a big upgrade in its search capabilities with last Friday’s build.  For reasons of simplicity and time-to-integrate, the first builds’ search capabilities were based off the legacy application’s model of defaulting to a customer name search and using a combo box to change what you’re searching “against”.

Searching for Business Return

The first implementation wasn’t without its smarts, however; I built in some metrics to determine what users were actually searching on and discovered that last name searches were only used about 10% of the time, and of all the fields used to search against (27), there are really only 8 things people use to find customers (and Account Number would have been a better default).

I took those results and went to speak with the users about their search experience.  It turns out that most of these search techniques were learned because of how they found customers in the legacy system.  Depending on what you were going to search for, you could be as many as 8 clicks away from a customer record in that app, so they have even mentally trained themselves to pattern searches in the easiest way the software works, not necessarily what they have for information at hand.

Also, for the most part, there was a common problem with how they searched for things and where they had to go to do so.  Rather than focusing on the task the user would try to execute on a daily basis, the software was organized into groups of data that were related on the database.  The search for customer was in a different spot than the search for a tower.  Could you imagine if Google had a different page for each search topic?  Beyond that, the summary information returned from the search was only useful to confirm the result was what the user was looking for; users had to drill into multiple results and then back out if they didn’t find what they were looking for.

Goals for Improving Enterprise Search

There were three major things I wanted to accomplish:

1. Infer the search type based on the user’s input.
2. Increase the relevancy of the information returned.
3. Provide search access from anywhere in the application.

I’ll start with three.  It was the last thing on the stack.  ;o)

I took a bit of a shortcut on number three and have spent the least amount of time on it, but it is still an improvement over the legacy system.  All I’ve done here to-date is incorporate a dashboard system and an easy way to get back to the dashboard from anywhere in the system.  At the top of the dashboard is the search bar, which has focus on page load.  Users are now two clicks away from seeing their search results from anywhere in the application.

Popping off the stack, we’ll discuss number two next: search result summary.  I have to admit on this one I’ve taken a bit of a cue from the major search engines.  You know how if Bing thinks you’re looking for videos, it will show you a few videos?  Or if you search for something that seems like an image on the main Google search, it will show you a few image results?  Well, I took a bit of that approach.  If a user is searching for a tower, they don’t need to see a phone number or street address, they want to see number of customers on that tower, and the status of that tower.  Likewise, if they are searching for a customer, there are certain pieces of information that are more relevant to the user. 

I even took that one step further, because the role of the user influences the styling and information contained in the search result.  For example, an account manager is likely looking for contact information and contract details, whereas a help desk technician is looking for recent tickets and the current status of a customer’s connection.

That accomplished, I needed to tackle number one on the list: inferred search type.

This turned out to be a lot easier than I was expecting.  I have written a series of regex expressions to identify the kind of search a user is performing and compiled them to a DLL.  I pass the search string into a method which returns the appropriate search provider and takes care of building queries, LINQ to SQL or calls to stored procs (depending on the system I am accessing).

To tie one and two together, I use the search provider to return a function mapped back to a controller, which then executes the appropriate build and bind sequence for the result list.  This is done through AJAX/jQuery and the MVC framework.

Acceptance?

It’s different.  It isn’t what people have been using for the last eight years, so I expect some friction. But a big positive is that everyone agrees it’s faster and I’m getting all kinds of suggestions for things to add, which means they’re using it (and are interested enough to see it move forward)!

For the time being, the legacy application is still the workhorse in the enterprise, but I’ve now created a bridge from Raven into that system.  What users have now is the ability to search much more quickly and then use the bridge to link into the old system, hopefully that doesn’t prove to be a pain and over the long term it helps the users transition into Raven.