We publish a fairly large online travel directory that, initially, was designed to be navigated mostly by just the search engines - so Google et al would pick us up better, faster and more efficiently. Search engines are robots. This causes a major disconnect in user experience when the users happen to be human.
So we needed to change it in a big way. By big I mean we needed a do-over. The most important thing about a do-over is to identify your previous mistakes and to make sure you don’t repeat them.
This is the fundamental flaw of most website “redesigns” - the belief that adding some new imagery and colours to a site will turn it into something wonderful. More often than not, the reality is the same reality that renovators face when renovating a house - slapping a new coat of paint on top of shoddy workmanship and a rotting infrastructure will end up costing more in the end than doing it right the first time.
How better to start fresh than by really starting fresh and, as a result, redefining the way directories (and dare I say search in general) are built.
The future of search, I think, is based on the belief that humans know more about what they want than machines do. Some believe technology and algorithms are ultimately more intuitive than human thought.
(ref) Matthew Glotzbach (Director, Google) argues that the computer should do the work and figure out what people need from whatever information is available:
“In the distant future we will not be able to get you to take more action … We will get close enough with what you give us. A lot of emphasis will continue on doing that in the background — getting the technology to figure out [what you want],” [Matthew] said.
There are dozens of theories of how to make search better, but they all basically boil down to human vs. machine. Whether we can make the search engines smart enough to understand our ever-evolving online search trends, or the depressing suggestion that humans will have to forfeit to the machine and conform to the rigid structures and functionality of today’s search engines.
So what’s our solution?
Well, for now we’re working on the theory. But it’s based on user generated taxonomy. Letting the users decide what’s relevant to what they want and giving them the tools to filter out what’s not.
Here’s the initial mockup of how I see it working:

At first glance it’s pretty standard. You type in what you want and where you want it. The power lies in the next step.
The next step is to just display a list of results. Right?
What if there are several hundred golf courses? Do you really expect your users to scan the entire list then click “next” when they don’t find the one they want? Would you? Ok, so maybe you would - but, given the choice, is that want you want to do?
The next step should be the filtration process. The refinement process. This is where the power of taxonomy and technology need to be integrated, allowing the user to quickly filter the list of results based on their own criteria.
So maybe they just want to see the golf courses in Phoenix. Or Tucson. Or maybe just courses with 36 holes. And then once they have that filtered result set, they should be pretty close to what they’re looking for. If not, give them the option to get even more granular, if there’s any data left that can help filter the results.
This theory is nothing new - it’s something that’s on the tips of everybody’s tongues when they’re browsing through search results. “I wish I could just find the results with…” or “Why can’t it just show me these…”
Going from command to choice
The challenge is merging the wants and desires with the resources to accomplish them. Current directories/search engines give the perception of choice, but do they really permit it? In reality, not really. Sure, you can configure your Google image search to only display large images - but is that really choice? Why not let users display only large images with the colour red in them? That’s a choice. And the technology is available yesterday to do it.
A basic example of a common directory shows its rigid database structure:
- name
- description
- address
The variables to search aren’t many. You could build a simple “what & where” search that produces a list of all matching results to a given command. Maybe even do a search of the description to get even more accurate. But the real power is in giving the user choices, but not too many. And the choices they have should be directly applicable to whatever it is they’re after.
Back to our golf course example - so now we’ve got a list of all 36 hole golf courses in Phoenix (or Tucson, depending on which we chose). Some further choices may be: public or private, practice facilities available, twilight rates available, hosts tournaments, has a clubhouse, has locker rooms, has a proshop. These are all choices that are linked directly to the command provided by our user and are all choices that will help in narrowing their search to exactly what they’re looking for. Keep in mind that not all of these choices are immediately available to the user. We don’t want to overwhelm them. So the subchoices are introduced with each subsequent choice.
How can a directory’s database be structured to accommodate golf course information while also accommodating ski rental shops? In a word, taxonomy or:
“things that are arranged frequently in a hierarchical structure, typically related by subtype-supertype relationships, also called parent-child relationships.”
The key, then, is to not build the taxonomy ourselves - how can we few possibly know how you many relate everything to everything else? Our plan is to let our taxonomy grow organically by user input. When somebody submits a directory listing, they will have a number of “tags” at their disposal to attach to their listing. So a ski rental shop based at a ski resort may add the tags “ski”, “snowboard”, “boots”, “bindings”, “rent”, “chalet”, “hotel”, “resort”. The more granular they get with their information, the better chance of being found by potential customers.
So that’s our plan for our directory. We hope to launch the latest version of it very soon and then tweak it as we go. There will be some hiccups and growing pains once we roll it out, but that’s all part of the process to refine something that’s good into something that’s great.
For more, check out the semantic web.
0 responses so far ↓
There are no comments yet...Kick things off by filling out the form below.
You must log in to post a comment.