A simple case of aggregating search

Search is one of those things that seems simple but is difficult to do well. The most common problem users tend to face when searching is that either no results are returned, or there are too many irrelevant results.

On a recent project we had the case of a simple keyword search bar that not only had to return relevant results but aggregate data returned from several sources. The user expects to type a search and get nicely-formatted results that match their query. Our problem was that the results came in multiple formats from multiple servers with quite variable response times.

The project in question was a Google Maps API and Google Local Search API powered Facebook Application. A search query could match one of several things: an address (Google Maps API Geocoder), a business or landmark name (Google Local Search API with the current view port of the map), a user’s name or personal details (either from the local database or via the Facebook API), or a game location (from the local database). The Google-related searches are done in JavaScript and the Facebook/local database ones were SQL queries in PHP.

Our initial implementation was to have tabs. The Addresses search was run, results were shown, and the other inactive tabs when clicked would carry out their respective searches. The problem was that there was no guarantee the first search type (addresses in this case) would return any results, and if the businesses search had returned results it would have been much better to display that first. The tabbed interface was also very disjointed, as swapping tabs had to perform the search (causing a delay), and users expect switching tabs to be instant. Also, the usability suffered, because if the search resulted in a few matches of each type, you couldn’t see them all on one screen.

The final implementation was in two parts. Firstly, all the searches were executed in parallel via Ajax, displaying and updating a progress bar as each was completed. This visual feedback helped offset the now-longer delay before any results were displayed. Then the data returned from each API was normalized so it could be fed to a single HTML render, facilitating output into the same screen. This allows the results to be displayed in a single list, grouped by type. Types with no results (or ones that timed out) are omitted from the output, pushing the relevant results to the top.