Building a useful not-found search results page

Big trucks, nothing found

I once worked with a client who sold trucks. Big trucks. Trucks so big that their “light” vehicles regarded my car as a speed bump. And they sold plenty of them. The first set of data was a 8MB, pipe-delimited text file that, I was told, could change daily.

Writing a script to interpret the data in a timely manner was challenging, but doable. The search tool I wrote handled 237 pages of results, eight trucks per page, on its trial run. But the interesting part came when we didn’t find trucks.

At first, if a search yielded no results, the site displayed a “nothing found” message. But I wanted to do more. I wanted the site to say “that search didn’t work, here’s why.”

Searches worth the effort

I wrote a MySQL query find out how many new and used trucks of each brand.

SELECT
	COUNT(v.id) AS tally,
	CONCAT(make_title,'-',vehicle_type)
FROM
	
WHERE
	mk.id = md.make_id AND
	md.id = v.model_id
GROUP BY
	CONCAT(make_title,'-',vehicle_type)
ORDER BY
	make_title,
	vehicle_type

In English: Find how many of each truck are in the database. Label them like “Ford-used” or “Volvo-new”.

Once I knew which models were in the database, I could provide links to people that would guarantee results. Even better, the script helped people make an informed decision by revealing how many results to expect.

example of the no-results screen

Clicking a number in the table at the intersection of, say, new and Mack, would search for new Mack trucks.

Unexpected results

This query (modified to remove sensitive data) produced surprises:

The client used these unexpected hiccups to clean up their data over the next week.

Rather than leave people at a dead-end, the vehicle search tool was helpful, unobtrusive, adaptive and useful in ways we hadn’t imagined.

Tags: case study customizing problem solving