Collaborative search on the rise?


I am seeing an interesting not-quite-yet-a-trend on the emergence of collaborative search tools. I am not talking about research tools such as SearchTogether or Coagmento, but of real companies started for the purpose of putting out a search tool that supports explicit collaboration. The two recent entries in this category of which I am aware are SearchTeam and Searcheeze. While they share some similarities, they are actually quite different tools.

Searcheeze (which might as well be pronounced Sear-cheeze) is essentially  a shared bookmark site organized around a bookmarklet UI. It lets you organize your snippets into topical categories, and lets you share these with your collaborators. The search part is not actually collaborative at all. In this way it resembles Coagmento much more than SearchTogether or more deeply-mediated tools. These guys went for a “low-hanging fruit” solution, which is a defensible strategy, particularly for new companies. What is much harder to understand is their stupid rhetoric that casts reference librarians as evil hags. (No, I am not making this up! Watch the video on their site!) Not only does it malign a well-respected profession and its practitioners, but, even more bizarrely, their presentation gains no rhetorical advantage from doing so! So I don’t know what these guys are smoking, but they are blowing a lot of it.

SearchTeam seems like a much more solid enterprise, one that actually provides some real support for collaborative search. It also implements UI-level mediation only, but it has a number of additional tools, including within-topic search history, the ability to save or hide search results, to add comments, chat, etc. These tools make it possible to work independently, but also to share your activity with your collaborators. SearchTeam has some nice awareness features that notify you of your collaborators’ activities such as saved documents.

There is still much interaction work remaining to be done:

  • For example, the design of the folder view (where saved documents are found) wastes a lot of space, making it difficult to see a reasonable number of documents without a lot of paging. The view also doesn’t highlight newly-added documents, making it hard to recognize changes initiated by collaborators.
  • It’s also a bit odd that when you save a document from the search results, its entry is removed from the list. While that does allow the user to focus on what’s left, it doesn’t make for a good sense of progress, and you cannot easily compare the next document snippet you’re examining to some of the ones you’ve just saved.
  • Queries are not shared with collaborators until a document is saved, and even then, no notification is generated. Overall, I think the search history deserves more prominence in the UI.
  • The chat window obscures a significant part of the workspace, and when put away pops up again immediately with an incoming message. While immediate notification of communication is typically a good thing, it should not interfere with what you’re doing until you’re ready for it.

SearchTeam does not maintain its own index (it probably uses the Bing API), focusing on the interaction instead. The advantage of this approach is that you don’t have to compete with Google and Bing; the disadvantage is that you’re limited by the API of the search provider. This may constrain your ability to do algorithmic mediation, to implement novel ranking or relevance feedback algorithms, etc. It does, however, make it relatively easy to deploy a usable and useful system quickly.

In short, there is more work to be done here, but the first steps are encouraging.