Feb 16 2008
Rethinking mail clients
I’ve been slowly coming to the conclusion that email as I currently practise it is broken. I don’t know what the answer is, but the current way mail clients are organised isn’t working for me.
I’ve been thinking about the best way of organising the mail I get — how I would prefer different types of email to appear in the interface, depending on sender, recipient, subject and so on. And have come to a few conclusions that I’ll outline below. The gist of it is that email isn’t really one way of communicating, but three, all using the same underlying protocol.
Three different types of conversation
- Unicast
-
Sending personal email to a single person. This is half of a conversation, and may well develop into a conversation. At some point this conversation may die, or be forked into the next type.
I think of this as being like real post. Each message arrives from a unique person, but it’s all to me. It doesn’t matter which address it was sent to, only who it came from.
In this state, I would like to have email sorted by the sender. So I can instantly see by looking at my mail client that I have a message from Helen not just I have a new message. To do this at the moment I have to create new folders (one for each person I know) and filters to reroute mail from my inbox.
- Multicast
-
This is a group conversation, but one that I’d define as “among friends” or similar. So if there are five of us agreeing to meet at the cinema, this is how we’d do it.
I like to imagine this as a real conversation. We’re all sitting round a table talking to each other. If I want to, I can fork the discussion and create a private discussion between me and some other person (ie, unicast).
- Broadcast
-
This is the one that’s least like anything that I can think about. It’s a proper bulletin system. I’m sending and receiving messages from people I don’t know — on topics I may have no interest in — and most of it is overwhelming my real conversations with people I know.
In this case the actual people posting the messages doesn’t really matter. (Obviously it matters within the context of a single conversation, because who-said-what always matters. But for the sake of sorting and organisation, it doesn’t matter.) The discussion list is all that matters — I only need to know, there are 17 unread messages from Haskell Café.
There aren’t any mail clients that I know of that have this three-stage approach to mail organisation. There seems to be an implicit assumption that everything coming in to the inbox stays there if there is no further user intervention. Which is why, given a few days away from my home or work email, the messages mount up to unmanageable quantities and I resort to generalised purges.
Explicit mechanisms for level of conversation
I want to be quite explicit in what I’m looking for. Most importantly, I would like the behaviour I’m describing to be default — requiring the least configuration to work at all.
Imagine the now-standard format for a mail client, with a slim bar for folders down the left hand side, and the remainder divided into (top half) contents of that folder and (bottom half) content of current message. A bit like this:

I would like something different. There should be three different view (maybe tabs or similar) for unicast, multicast and broadcast messages1. This is how they should be organised:
Unicast: Dialogues
There should be a separate folder for each correspondent in your personal address book. So all your friends and family get their own folder. But only the folders that have new mail should appear by default. The others should be invisible so as not to overwhelm the screen. This is a bit like the friends list in instant messenger clients — you can optionally look at everyone but by default only the people who are online appear in the list.
I’m not sure what to show if there are no new messages — possibly the N most recent correspondents, or maybe nothing. Of course there’s a big and easy button to Show All at this point, if you want to find the last thing someone said to you.
Messages which come from unknown correspondents could get a New or Unknown folder. I’m not sure about this aspect. Or maybe there should be a different folder-view for every sender, whether they’re known to you or not? Either way, I envisage known senders to be treated differently. And there should be a way to recognise common addresses even if you don’t correspond with them. For example, mail shots from online stores which (a) aren’t your friends and won’t go in the personal address book (b) but similarly aren’t unknown to you. It should be easy to mark messages which fit this criterion so they all fall into a Adverts folder or similar.
Multicast: Group conversations
Group conversations are pretty easy to spot but hard to classify. If you’re not the only recipient then it’s a group email. The only exception I can think of are if the sender CCs another address which belongs to you or to them. But the address book should be able to recognise this situation and strip out duplicates before further analysis.
The hard part is how to group these messages. Thinking about some general use cases (friends organising a night out, people working on a joint project) it seems that the subject is an important classifier. A couple recent examples, one from home and one from work:
- A friend emails to suggest we go to the cinema. The subject is “Movies anyone?”.
- A discussion about a bug at work. The subject is the bug tracking ID.
These are both pretty short — a couple of words or less than a dozen characters. Looking through my inbox this seems to be the way people write subjects. In fact, the only long subject lines in my inbox are from:
- Adverts from Ticketmaster or Dabs telling me about their latest and greatest deals.
- Automated systems which generate subject lines by joining various IDs, subject headline and other stuff into one massive long “message in a subject”.
- Mailing list users trying to sum up their discussion point/problem in a complete sentence.
None of these messages are group conversations. It seems to be a feature of intimate human conversation that people use very succinct subjects. I wonder if this intuition is universal, or near enough to make little difference?
Anyway, my thought is that most people write so little for their email subjects that the folder names in the left-hand column could be the subject lines. I’m not really interested in knowing in advance that a particular person has sent me a message. I’m more interested in knowing that a particular conversation has continued, so grouping by conversation seems natural.
Unlike the person-to-person email, it seems less important to hide conversations that don’t have new additions. But there still needs to be some metric by which conversations fall off the radar. So I think old conversations, ones which haven’t been updated recently, should disappear. Maybe something older than a few days is too old? I’m not sure, but that’s my initial feeling for how things should be set up.
Again, none of this requires explicit organisation. The mail client creates these views based on new messages. I think if it’s obvious that a continuing thread has been forked it should be easy to create a new conversation from it — a Fork button or something — but otherwise everything should be managed by the mail client. Certainly if a message goes from being called “Movies anyone?” to “Birthday gifts (was: Re: Movies anyone?)” then that’s a good indication that the conversation has been forked and the new topic should be “Birthday gifts”.
(I just found a small usability study of email subjects which bears out one part of my intuition but refutes another. It seems that short subjects are considered more effective by the recipients, but most people write long ones. Ouch!)
Broadcast: Public message
The final category, of group mailing lists and the like, is the easiest. It’s actually the most like how current mail clients work, or even newsgroup readers (which are largely very similar but seem much better suited to their job). So, the folders in the left column are the different lists you’re subscribed to. In mailing list mode the default reply should be to the list (something that Thunderbird and Gmail get very wrong).
The mail client will have to be told which groups you’re subscribed to, but that seems sensible anyway — then it can reply to the right places. (I often get caught out when hitting “reply all” because someone has sent the same message to two mailing lists. Then I receive a “cannot deliver” message from the list where I’m not an registered subscriber. I don’t know what the best way to do this would be, since it’s not obvious which is a mailing list and which is a real person.)
Writing too long! Help!
So it seems like I’ve been writing forever today. I suppose the next step is to look at Thunderbird to see if it could be altered to do what I want. I guess that it’s quite a hefty job and I know nothing about coding for XUL.
I’m happy to have written it all down though. I may attempt to explore the problem a bit further later, to clarify my thoughts more. Who knows, maybe someone else will be inspired to do something where I can’t!
-
Can you think of a better set of names than these? Maybe private, group and public? I’m not sure. Suggestions welcome. ↩
http://www.mozilla.org/blue-sky/misc/199805/intertwingle.html, that is all. For now.
Hmm, it seems that every time I post something then Lawrence comes back to me with something written by Jamie Zawinski. :-) Maybe I should be doing a pre-emptive link to everything he ever wrote with every post.
But please, do continue.
Given the areas he’s worked in (and being a not bad programmer), it is perhaps unsurprising. Sorting by sender (each sender into a unique mailbox) is easy given access to procmail or sieve. Mapping multiple senders to a single person may require a bit of work but should be doable. If you read your email with a newsreader-like client the default is ordinarily to only show new messages. If you use gnus, folders with no messages do, as you want, not appear.
The second group is clearly the hardest to deal with, it seems more like you’d want to use References: headers to group emails and then further use changes in subject to distinguish them further. A further issue is the method people use to keep on sending emails to groups of people (which makes life harder), they just reply again maybe not changing the subject, but changing content. I guess it’s a bit like the classifying spam problem, incredibly easy for a person, but somewhat harder for a computer. With a sufficiently large corpus of mail you could do some kind of Bayesian analysis and create rules appropriately. I think it’s the sufficiently large requirement that makes this a no go.
As for mailing lists: get a real email client :P.
Lawrence