in an Omnibox
Turning Sentences in to Input Fields
If there’s one thing Google has spoiled us with, it’s the ability to throw a bucket’s worth of words in to a single field and expect magically-relevant results to appear.
It doesn’t hurt that they’ve got an army of PhDs on staff who not only know a thing or two about ranking algorithms, but apparently also know how many golf balls fit in a school bus.
For the rest of us mere mortals trying to cobble together an enjoyable search experience for our customers, we often find ourselves at the mercy of overwhelming search forms that intimidate our users.
The Double-edged Sword of Advanced Search Forms
At Mocavo and FindMyPast, we have several hundred thousand datasets in our indexes. Our customers can search the entire index at once, or they may choose to zero in on a given dataset and search it individually. One such dataset is the very popular 1940 United States Census which has 14 unique columns – and as a result – requires a search form that’s on the cluttered side of cramped.
We’ve tinkered around with hiding some of these inputs behind a “Show Advanced Fields” toggle, but that’s had mixed results. And besides, it doesn’t change the fact that once the customer reveals the advanced fields, they’re still looking at 14 inputs.
Inputs, that by the way, can be really useful. If use the following column-specific inputs, I’ll find who I’m looking for (my gr-grandfather, Thomas Jefferson Tallant) right away:
- Last Name: Tallant
- County: Lamar
- Birth Place: Arkansas
So, searching structured data by column is a great way to dramatically increase the relevancy of results, but still, we want a more approachable means for customers to find what they’re looking for that doesn’t begin with this barrage of fields.
Structured Search in an Omnibox
The notion of having a single search box for a more “Google-like” experience has floated around our offices for a couple years, but how exactly could it be pulled off? Take the example I just used above: if I throw “Tallant Lamar Arkansas” at our search engine as a string of keywords, the likelihood that I’ll get decent results is very low. “Arkansas” will find matches in several unintended columns: Last Name, City, County; the same will be true for Lamar. You get the idea.
But what if we know that Tallant is almost always a last name, Lamar is probably either a last name or a county, and Arkansas is usually a state? If we have a library of likely values to compare the customer’s input against, could we make an initial best guess and provide the user with some UI for correcting our assumptions when they’re wrong?
I think so:
As you can see, if we think the word is a name, a date, or a place, we indicate that best guess with a person, calendar, or map-marker icon.
This takes us in the direction of a simpler and more approachable search experience, without losing the accuracy of the column-based structured search that our market expects.
Notice how when I entered “born 1980" that it merges those two previously separate fields together. We could expand on that sort of contextual intelligence in a number of other ways. For example:
When Jackson is on its own, it’s usually a last name. But, when followed by Mississippi, it is almost always a city; so the column assignment changes when its context changes.
Teaching Syntax on the Fly
I showed the prototype to Drew, one of our developers, and he had an interesting idea that would educate users on the syntax of commonly used terms like born, died, married, etc.
Power users will learn these time-saving hints as they go until they become part of their natural workflow.
Correct Us When We’re Wrong
Of course, sometimes our first guess will be wrong. In which case, the customer will be able to change the field type and resubmit their query.
Few things are as obnoxious as the unsolicited redesign shamelessly promoted on the Twitters. So trust me, I’m not suggesting that the following sites are not already doing amazing work and giving their customers a fantastic search experience. As I was iterating this prototype, I couldn’t help but wonder how it might be applied to other services.
Already one of the easiest travel sites to use, what if instead of this:
You saw this:
We’ll be kicking this around internally for a little bit and getting it wired up to some live datasets for testing. But, I’d love to hear your thoughts and suggestions for improvement in the meantime.