We have been giving a lot of thought recently to how we can improve the Search function in Kerika, and in the process found ourselves thrashing between different design approaches — all of which seemed deficient in some respect.

To get a better grip on the problem we decided to put aside all of our designs and step back to think more deeply about the basic uses of Search.

We concluded that there are three trajectories of Search that we need to consider:

SEARCH FOR RETRIEVAL

When you are trying to find something you have seen before: an old card, an old project, and old chat message.

You know for sure that the item exists; you just don’t remember where you last saw it.

The goal for a Search function in this scenario is to minimize user frustration by reducing the number of clicks needed to find and retrieve it.

This assumes, of course, that the object that you are trying to retrieve does really exist: if its your memory that’s faulty, then the goal of the Search function must be to convincingly demonstrate that the target object doesn’t exist.

It’s easy to imagine examples of Search for Retrieval in the context of a Kerika user:

• “Where’s that contract that Arun signed last week?”
• “Where’s the card where Arun and I discussed making changes to the contract?”
• “Where’s the canvas where Arun laid out the product vision?”

Search for Retrieval is not an important use on the Web, when you are using Google or Bing, because important items are more often bookmarked or scrapbooked for faster and more secure retrieval: if there is a Web page you need to return to often, you are going to rely upon your bookmarks more often than a new Google search.

But in a content management system like Kerika, which also integrates conversations, tasks, processes and people, Search for Retrieval is a critical use case.

SEARCH FOR EXPLORATION

Exploration differs from Retrieval in one fundamental way: the user wants to use something that exists as a starting point to discover other items that are related.

Exploration is about attacking a problem area from many different angles: you might not be  certain what content exists that’s relevant, but you are certain that some relevant content does exist.

Examples of Exploration in Kerika might include:

• “Where are all the bugs we have fixed regarding this feature?”
• “Where are all the contracts we have signed for this kind of work?”
• “Who are all the people who have worked on search engine technology?”

For Exploration to succeed, we need to create moments of delight: if a user can easily find related information that they were really hoping does exist, then the experience of quickly finding this information is sheer delight — and delight is a completely different emotion than the absence of frustration.

Exploration is possible on the Web with Bing and Google: the search engines try to help you auto-complete your query, offer suggested searches, and try to cluster results by type: e.g. here are all the images that match you search, and here are all the videos that match your search.

SEARCH FOR DISCOVERY

Discovery is closer to Exploration than Retrieval, but different enough from both that we think it is worth considering as a separate search trajectory in it’s own right.

With Discovery, you are hoping to find something, but have no real certainty that anything exists.

This the crucial difference between Discovery and Exploration: with Exploration you are fairly certain something exists, but are not sure in what form the information exists, or where it can be found. With Discovery on the other hand, you are really venturing into unknown territory, with no assurance that anything might be found.

In the context of a Kerika user, Discovery might take the form of questions like:

• “Have any bugs every been reported for this feature?”
• “Has anyone ever looked at this issue?”
• “Is any work happening with this client?”

With Discovery, we need to combine elements of both Retrieval and Exploration when considering the user interface: if no information exists, then how quickly can we let the user know that there is nothing to be found? In other words, how can we reduce frustration?

On the other hand, if something does exist that is worth discovering, how can we present the search results with good information scent?

CONCLUSION

It’s probably hard to support all three search trajectories equally well: we need to decide which search trajectories are most important in the current context of the user.

We could try to get clues from the user’s current view of Kerika — which project or page she is looking at, and which one she was looking at before — to try to guess which type of search trajectory she has in mind, but these guesses are not likely to be very accurate, and forcing the user to go down the wrong trajectory can be both frustrating and counter-productive.

We are still exploring these ideas, but look for a new Kerika Search in the coming weeks…