Retrieve or Search - Different ways of accessing filed emails
Whenever I need to access the ticketing and source control system we use for Tagwolf, I go into my email client, type “cloud” in the search box and hit enter. Somewhere in the top three hits is an email from my business partner informing me that the service with our cloud-based service provider is now operational. The email contains a sentence “…ticketing systems are now in the cloud.” and a bit further the URLs where I can actually access these systems. I click the one I want and am done!
What I describe is a search in my email repository, signalling that I have arrived at the last part in the series about my filing habits, covering how I search. It is also an excellent illustration of a point I made earlier in the series that my email repository is an important tool, my professional memory if you want.
But let’s get our concepts straightened out first. Actually, I may have created confusion by calling this post “how I search”, because there are two related concepts: one is retrieval, which is what we do when we want to find back something that we have stored somewhere; the other concept, which I’m doing in the example above, is electronically searching for an item stored somewhere. Searching is just one specific way of retrieval.
This last option -search- is a bonus we have received when switching to electronic information. Indeed, in the paper based systems of the old days, our only option to find back (retrieve) an item was to find its (physical) location. To make this activity feasible for larger repositories such as libraries with tens of thousands books, the items where organised in a structured arrangement, such as a classification by author. This structured arrangement is nothing else but the paper equivalent of the taxonomy or folder structure that I introduced as a key element of my email filing routines in the previous post.
And that brings us back to the electronic world of today and the way I go about retrieving filed emails. The electronic equivalent of looking something up in the library is manually browsing through my folders to find an email. I use this way of retrieving emails in two cases. The first is when I can’t find an email by doing a search and the second is when I want to do a systematic scan of one or more folders, for instance when I am producing a report and need all the emails linked to a certain topic. As said in the previous post, the characteristics of the folder structure are essential for this type of retrieval: folders with an unclear scope or a high number of emails will definitely turn this into a nightmare. If, on the other hand, the hierarchy helps me narrow down the target scope to arrive to a small set of emails, the folder structure can be extremely efficient to find back emails I need.
And then there is the bonus we got when switching to an electronic environment: search. You already saw one example of how I search for emails in the introduction. Search has a major drawback however. Its reliability depends entirely on the search terms used. This issue manifests itself in two ways. The first is that I know that I have an email about a certain topic somewhere, but can’t come up with the correct search terms to retrieve it. The second is more subtle and trickier: when I’m looking for several mails about a certain topic and get some search results using a certain set of keywords, how do I know that my result set is complete? Or, the opposite happens: I type in some search terms, but get back too many search results. In all these cases I often end up going manually through the folder structure anyway, just to make sure that I have the complete result set and nothing else.
So, if we look at the “bonus” that we get from search, we see that it is has its limitations and that in several cases, we have to go back to retrieving emails using the folder structure. And what about the small example I started the post with? I do use a search for that, but I can imagine some people being a bit surprised by that approach. Indeed, search is a clumsy way to accomplish what I’m after in that case. Search in that case provides a function that could be automated by a context aware application, which is part of our global vision as we explained in the post about context switching. Indeed, one of these cognitive assistants should be able to analyse the information I’m working on and associate a context with the activity I’m doing. A context in this case could be for instance a project, a customer, or another group of related emails that makes sense. Based on that context the application would provide me with all the relevant information I need for that context. Again I think that this “context retrieval” would use a taxonomy to accomplish this.
So retrieving filed emails (and information in general) relies on the folder structure in which the emails are stored. In certain specific cases, we can accelerate the retrieval by doing an electronic search, but it has its limitations. A well-structured folder structure or taxonomy is not only essential as fall-back solution when search is not appropriate, but is also something that will be the basis for interesting new solutions.