Searchable

Searchable is a lightweight application I wrote for use in a corporate intranet. It is a good case study in how the simple answer is often the most effective.

The design goal for Searchable was quite simple:

• The corporate search engine did not cover all of the content employees needed to access
  
• Several applications had their own search interfaces
• Employees couldn't remember where all of the content was
• Design goal: improve this situation

The design constraints were that we did not control the corporate search engine (we could not change its scope) and we could not replace it or compete with it (both for political and resource reasons -- we did not have a server sufficient to run our own search or produce a federated search).

The team had already tried providing a web site with links to all of the relevant resources. That had -- not surprisingly -- resulted in little significant improvement. It was just too cumbersome for users to jump from site to site, find the search interface, search, fail, then back up to the list and repeat.

What the users wanted was a consolidated or federated search: perform one search and have all the results in one place. This is usually expressed by the exasperated question "why can't we just use Google?"

Since federated search was technically beyond our means, I tried the next best thing. Rather than federate the results, I federated the interface. The result was Searchable.

The key to Searchable is that it provides a single interface. Enter your search terms, select a target, and press Go. The search box remains with the results in a frame underneath, allowing the user to switch targets and search again without losing context or having to jump back and forth. From a design perspective, the entire application operates in the browser (the client) and doesn't require any server resources except hosting the files.

My initial reaction, beyond being proud of the implementation, was that it wouldn't have much impact on the original problem. It doesn't do anything new: the results are the same and the user still has to search each site separately, even if I simplified the process.

But to my surprise, the users were happy, very happy. I could tell because they kept asking for new features and additional targets. (The e-mail link was one such addition, so if they found something they could e-mail the current search results to a friend.)

It seems that simply putting all of the search targets into a single input form was sufficient to alleviate much of their frustration with the fragmented content. They hadn't realized it was possible, so it looked like magic to them.

Searchable Revisited

The other assumption I made about Searchable was that it wasn't much use except on an intranet. I figured the internet is open enough and search engines like Google and Yahoo! are thorough enough that there was no need for a federated interface. (Besides, there have already been federated search engines like Dogpile. What could I provide that they didn't?)

But I actually answered the question myself one day when I was looking for some images online. I found myself trying Google first, then Flickr, then other sites. This was both tedious and not terribly rewarding, since I had to keep entering the same search terms.

So one aspect of Searchable which is not addressed by internet or federated searches is logical scoping by topic. Oh, search engines do segment by content type (images, video, maps, shopping, etc.) But the results are neither complete nor easy to sort and decipher.

Another aspect of searching (which was not originally addressed by Searchable but that I added for this version) is localized preferences. Some search engines allow you to refine your search based on various criteria. For example, if doing job searches you can specify the location to search. In many cases these are attributes that do not change from one search to another. So I added the ability to set and save advanced properties for specific search targets as part of the change options... function.

Try It

This version of Searchable is just a demonstration. I've provided some example targets. There are many more that could be included. The same goes for the advanced properties.

The technology is most powerful when tweaked for specific audiences (by adding and customizing the search targets to match the needs of the audience, such as a corporate intranet). But I have posted it as a sample so people can see it in action.

Pros and Cons

As mentioned above, the advantage of Searchable is that it satisfies a need. The disadvantage of a solution such as Searchable is that it is totally dependent on the REST interfaces of the target sites. If they change their parameters, rename them, or require new parameters, Searchable breaks. In the six months I managed an intranet version of Searchable, I had to update the mappings at least four times. So there is definitely a maintenance cost that needs to be considered before putting a solution like this into production.