Almost identical

When it really matters to find a particular piece of information, keyword search can be a problem. The phrase “Information Architecture” yields 43M hits on Google, and you are presented with only 10 hits per page. Just for giggles I went to Bing.com – the Microsoft site – and I rather like the way it presents the results. In particular, rather than having the silly goooooooooogle thing on the bottom they present you with a list of 5 pages to which you can navigate. They claim 71M hits. Regardless of whether there are 43 or 71 million, that’s a lot of data.

If you are looking for a particular page, you have a challenge. Maybe you can add other search terms if you are confident that you know what they are, or you can use the advanced search feature. Almost nobody uses the advanced search function. Why is that? Perhaps because once they have a list of possible hits presented to them, they start searching through the hit metadata (website, excerpt, date, file format, etc) in order to understand how what they are looking for overlaps with what they got in the results list. It is not at all clear to the user that time spent crafting a really good query will be less than exhaustively scanning the results on page 1 of the simple query. There are legitimate UI issues, too. This posting has some pretty good discussion about advanced search. One suggestion in that posting that works in a corporate environment is to construct the interface to cue on categories that you know will be helpful.

What do people remember about a particular design document they wish to retrieve? They may remember the author, the approximate date it was published, the type of document and some keywords, but the primary thing they are likely to remember with any kind of certainty is the name of the project in which the document was used. If you can start with the list of documents for the project, you are already almost there. This is especially true if your company encourages document reuse. When you have a thousand documents that all contain the word scalability, but each one is for a different project and is different in various subtle and hidden ways, then you want to start with something that you know will get you the exact document you need. The project list is very likely that list. Thus it is important to have an interface that allows the user to get quickly to the project list.

Usually the easiest way to create a user interface that allows you to navigate through project hierarchies is to structure the data itself according to the project hierarchy. But you are not necessarily confined to structuring your data into projects. Data can be organized physically in one “natural” form such as project hierarchy, but also you can create one or more structures containing references to the documents, and the user is free to navigate one of these alternate structures. For example, you can organize your documents:

• by author and date of initial revision
• by document title (as the initial filter) followed by project
• by type of document (as the initial filter) followed by project

I will draw some diagrams to give you a better idea of how this would work. The general idea is to have a user interface that promotes navigation to a subset of the data that the user is reasonably confident is already much closer to the final result than if you relied on simple keyword search alone.

Navigation fits nicely into the human thought process. Many people have trouble figuring out which keywords to type in to a search engine because the likelihood calculations they must perform prior to executing the search are abstract and require a thorough understanding of the domain and the language in which they are searching. But everyone can navigate through well-known spaces to find the information they need.

In a reuse world where most documents are almost identical, navigation is better than search as your starting point.