Cleaning is for cowards!

I'd like to follow up on Why search engines struggle to work inside a company? by Peter Hora, about how to make a company search engine better. Considering the increasing amount of information we have available to us, the search engine has become the most widely-used part of any application for all of us. But it's not one we're all happy with.


There are people, and I'm definitely one of them, who prefer to browse the whole hierarchy of data or documents, if you want, which are located in an application without "searching". Unfortunately, there's a point, after time and use, when the content inside the application, (data, documents) will have grown to such a size that to display it and orientate within it, without a search tool is almost impossible. So what do people like me do then? Well, we've just got to learn to cope with the situation and accept the "help" of the search engines. Breaking your routines is never nice. Isn't there a less painful way to make this transition and give users like me something to at least partly satisfy our needs?

When searching for content we mostly use full-text search engines, which are, it has to be said, very effective, praise and credit where it's due. The speed with which they can return the results in such massive amounts of data is amazing.

OK, so let's google the word “customer”. The result? About 1,520,000,000 results in 0.27 seconds. Pretty damn good! But, hang on, what should we do with all these results? Go through them manually? Scarey - No thanks, mister!

So what happened? Well, the search engine found all the available documents (pages) containing the word "customer", sorted them according to the part of the document in which the word was placed and according to other criteria (for example, the significance of a document) and returned links to these documents including a short extract from each.

How does this help answer our original question about how to satisfy at least in part the needs of users like me:)? Well, what if the search engine offered some context for those documents as well. Context like the address of the document, where it's located? A file's address can be basically anywhere, so that doesn't help much. No, what I meant was, what about displaying the context of a document from the perspective of its relationships to other documents? Now that would be useful!


There would be no need for the routine browsing of each document to find out where it belongs in the hierarchy. Users with such a wide-searching search engine would see part of the hierarchy directly in the results. Each result would be supplied with its context. The "physical location" of the document isn't the context we need, but its relationship to other documents is.

It's true, people place documents in folders, these folders are inserted into other folders, etc and the result is a hierarchical arrangement of sorts in terms of the documents' addresses. But this "location" hierarchy is fragile and contingent. When change occurs and files are moved or deleted, it vanishes. And the user has three choices. The first two are obvious: reorganize the entire system of file locations to restore some order. Or just lose it and let chaos take hold. Neither seem like good options to me. What about the third, the context of relationships I mentioned earlier? If we maintain order at the level of the relationships between documents and don't bother with tidying up file systems, will there be chaos? No, not with the Company Encyclopaedia, there won't.