Email, in essentially its current form, has been around for quite a long time. Almost as long as me, in fact. The design has been modernised since its inception but, for the most part, the same basic structures and protocols have been used for at least 10 years.
Despite email having changed little in 10 years (indeed not much in 24 years), the ubiquity of personal and corporate email addresses and the equipment and networks we use to exchange these messages have advanced by leaps and bounds. Around the time of the last significant change (being RFC 2822) a person inside Search giant Google began developing what came to be known as GMail.
Three key features of GMail were the concepts of labels, archiving, and conversations. These features have upset the apple cart in the email world for very different reasons.
Labels
Since very early days, email clients (more correctly Mail User Agents) have offered folders as a means of filing email for later retrieval. The concept of a folder is simple – a container into which one can place one or more emails. It is very similar in concept to the drawers of a filing cabinet, where a document can be placed in any one drawer. With the advent of IMAP (initially published in 1988), these folders were present on the server, too. IT was filing nirvana. Or was it?
I have been using corporate email for more years than I care to remember. Essentially since the beginning, I guess, as I distinctly recall using IBM’s PROFS system which predates the email we know today. In that time I have struggled to work out a structure of folders that I can reliably and easily file my emails into. I’ve never achieved it. I never will, either, because about 4 years ago I realised it was futile. A respected colleague had an impressive array of nested folders which he religiously filed his emails in. I stopped being jealous of this when I realised it didn’t help him one bit. Every time he was looking for an email that he remembered, he would look in at least two folders, often three or four. If you can’t go straight to the correct folder to find the email, what’s the point in filing it in the first place?
But using folders for filing presents a significant problem – the problem of giving each email a single classification. Although in some professions work can be fundamentally divided into discrete buckets this is certainly not true of the IT sector where I work. If I receive an email supplying two timesheet codes for different projects from the same project coordinator, then where on earth do I file it? Under “timesheet codes”? Perhaps. I can’t store it under a single project folder. What if the email also mentions a deadline for each project? Do I need a deadlines folder? This approach leads to either mutiple copies of emails (which I know some people do) or a huge number of highly specialised folders that become inefficient.
Labels solve this problem elegantly. A label is merely a tag, a sticker, a coloured flag. It is an attribute of the email, rather than an exclusive container for it. Because of this, multiple labels can be applied. For the example above I could apply the labels “deadline”, “timesheet”, “project A” and “project B”. This single copy of the email can then easily be located from any of those angles. Instead of viewing the contents of a folder, I filter my view of email to those that have at least the tag I am looking for, even if they have other tags. I can get smarter, too. I can ask for all emails with both ”project A” and “timesheet” which means I can quickly find exactly the information I am looking for. No folder structure could achieve that.
Archiving
However, even labels may not be necessary for efficient filing. At work, I am stuck using Microsoft Outlook, backed by an Exchange server. Outlook has categories which are similar to labels, but these are notoriously difficult to use and are therefore inefficient from the beginning. I do have a handful of folders to get things like automatic notification emails out of my inbox. But other than that, virtually nothing ever leaves my inbox. Rather than “inbox zero” I have “inbox infinity”. This is not ideal and I suppose I could cure it with a single folder to which everything gets moved when actioned. I do have “auto archiving” turned on which slowly empties out my inbox (which is all stored on the server) into a local file. This stops me hitting maximums, but I have to manage per-year archives to avoid maximums there.
Google solved this very elegantly with their version of archiving. Because no mail exists “in” anything in GMail, the inbox doesn’t actually exist – it is simply a label. If you archive an email in GMail, it simply removes the inbox label and the email seems to disappear. Except it doesn’t. It’s still there, whether with other tags or not. Combined with Google’s generous allocation of space (38 times the size my employer offers on the server), archiving is the ideal means of keeping email present without it cluttering up your current inbound emails and without having to think about “where to move it?”
And this is where Google’s core business comes into play. Search. Why tag your email when you can just search? Although I’m not fortunate enough to get to use GMail for work, I have used various products which index and allow searching over ALL of my email. It is by far and away the most effective means of locating emails I have ever used. Sure, sometimes I struggle coming up with the search terms, but this is no different to struggling to think which folder to place emails in. There’s no free lunch. I have recently taking to adding keywords to some of my outbound emails for the purposes of searching.
So you can see the combination of labels and archiving should be able to meet the needs of most people and meet them very efficiently. Google has advanced the state of play for the better, right? Unfortunately, no.
This where the “(and broke)” of the title comes in. Because Google are the only ones to make these advances and because no standards have been updated to account for these two differences, you are stuck using Google’s web interface if you actually want to make efficient use of them. As soon as you add an email client on any platform, you are into workaround territory. Labels pretend to be folders and your archive, which exists inside nothing, now has to live somewhere. This means lots of duplicate emails and contrived or impossible machinations to make any changes through the client that will make sense in GMail terms.
I’ve spent considerable time looking at email clients for my Mac and have repeatedly come to the conclusion that the web interface is the only practical one. Every other approach brings limitations or inefficiencies or both.
Conversations
So I already covered the fixing and breaking of email. Why are conversations left to last? Because Google have gone the opposite way here. They took something that worked perfectly fine and broke it in the name of “ease of use.” I don’t even think they achieved that.
The way Google build their conversation view is by crudely matching subject lines. This gives rise to “conversations” that are no such thing, such as a stream of notification emails from the same service. It can also give rise to broken conversations when someone changes a subject line. Although relatively rare, it is good email etticut to change the title of an email “trail” if the topic wanders. Google will split the newly titled email out of the original conversation, potentially losing the context of the discussion.
As far back as the original email specification (RFC 733, from 1977) there was provision for emails to be threaded by reference. Every email has a unique identifier in it and every forward and reply quotes the identifier of the original email. This makes it trivially simple for an email client to follow the actual thread of conversation, regardless of the subject line. I was using such an email client in the early 90s before the world wide web even existed. Quite how Google “invented” this inferior method (which was available in that early email client) and thought it feature-worthy is beyond me. It’s nothing more than a crude hack.
Conclusion
I’m tied into the Google email ecosystem for various reasons so it is unlikely I will change any time soon. But I do tire of the web interface easily (the new look one in the wings is worse!) and would like to be able to operate a native email client at least on my Mac. As of today, I don’t think that’s happening any time soon.
And if anyone is thinking of mentioning the Sparrow email client – I already own it. Their implementation of labels (which I do use on some of my GMail accounts) completely misses the point.