His Part 1 says in effect “email takes real time, so budget that time.” His points about never catching up if you try to just fit it in during an otherwise busy day ring especially true. I’d add that any reputation benefit you get from fast turnaround is lost by being that guy who is checking email during meetings.

His Part 2 goes into detail on his email workflow. I was pleased to see that my own workflow is similar – I don’t get nearly as much mail as he does (sending 225 and reading 400 messages a day? Ouch), so it’s nice to see that my approach could scale.

The high points we have in common are

• Separate work and home email accounts. Very important. I couldn’t agree more, and people who want unified inboxes in a mail client baffle me.
• try to decide what to do with an email the first time you read it, then archive it right away
• no filing, just one big Archive.
• filter lists out of the inbox ( I only do this for high-traffic lists, but my idea of “high” is not that high. )
• simple filtering – I don’t try to use filters to pick out “important” emails – my goal is to read every mail. If I can’t, I need to reduce the incoming flow, not tweak my mail client setup.

One difference is that he says he uses his inbox as a to-do list, where I prefer to move things to OmniFocus as soon as I understand what the task is. But it’s possible we’re just calling the same thing by different names.

He also does more manual management of his archive folder than I do – but maybe this is because there are less than 10,000 emails in there right now. I imagine his archives are bigger. Mail.app doesn’t have much trouble with mine.

Also my archive is a local folder – so it never has to sync with IMAP. This is due to a server mailbox size limit, and it’s not ideal. It’d be nice if I could see my archive on my phone, but hey, it’s only 2011.

In the comments to Chuq’s post, there’s a link to a really interesting proposal to make mailing lists easier to use – Luis Villa: “Mailing lists are parties. Or the should be.” The idea here is that the tools should help us give and receive some of the social cues that make parties successful where mailing lists aren’t, like politely showing someone that they’re boring or annoying you (by leaving the conversation), or quickly finding the interesting conversations (by seeing who and how many people are paying attention to it).

I really like Luis’ suggestions, because you could do this with mailing list software today.

I’m not going to re-post all of these, but I thought this one was worth pointing out because it shows some of the thinking behind the changes – and hints at an interesting design principle:

Detail views that don’t change visual structure when the item they’re displaying changes feel faster and more solid.

Do you agree?

They do say they’re working on some re-styling and finishing touches – so I’ll reserve judgement until I use it. For now, it’s still catch-up.

Maybe it’s to integrate comments from a bunch of people while you’re editing a report, or it’s a set of mails with instructions for something, like how to configure & install a source code package or submit expense reports in the new system. These emails could all be in one thread, but just as often it’s a few mails spread throughout several threads and scattered in time.

A good mail client should make it easy to keep arbitrary groups of messages visible for reference. Since they’re reference emails, you’re just reading them, and the display shouldn’t really be more than the text of the mail. You should be able to fit a few of these on screen without overlapping what you’re actually working on, and you don’t need a big toolbar with a bunch of actions that won’t be happening.

When I’m doing something in another app, I want to arrange my reference mails in an empty part of the screen, then not click back over to the mail client until I’m ready to close them. The faster it is to set up this display and get on with things, the better.

Let’s look at how a few existing clients support this kind of thing:

Gmail

It’s easy to open a conversation and refer to it, and you can hide the body of messages that aren’t relevant. But you can’t move things around, so if it’s a really long thread, you might be in for some scrolling. If you want to refer to more than one thread, you will have to open each in its own window.

Apple Mail

Because of its lack of a conversation-style thread view, the way to do this is to just open separate windows for each message. You can’t look at a single thread in one window – have to open N windows for N messages. Ugh.

Since Mail is what I use most often, when I have this problem I always end up with a flock of windows, and lots of clicking, scrolling and cmd-tabbing around to see what I need, followed by looking at all my open windows and trying not to close any unrelated drafts or accidentally send or delete something important.

Postbox & Thunderbird

The experience with Postbox is similar to, but a little worse than GMail. In Postbox, there’s a thread view where I can hide uninteresting messages like GMail, but if I want to pop the thread out into a separate window, I can’t – only single messages can be popped into separate windows. I can make tabs with the thread view by double-clicking on a thread, but I can’t figure out how to get a new window. Of course, if I need to see multiple emails at once, tabs are no good.

Thunderbird is basically the same, except at least in 3.0.4, the default view when you select a thread is less useful than Postbox’s – it looks more like a debug dump of the message’s text than a well-designed display.

MailMate

MailMate is similar to Postbox & Thunderbird – except that you get a nice linear conversation-style view with any selection, not just a single thread. (Postbox has a nice view but only for a thread, and TBird shows you any selection but not a nice view.)

Still, as with those others, the linear conversation view can’t be popped into its own reading-oriented window, and it’s strictly linear.

Summary

I don’t think any of the clients I looked at have a good solution for this. Is that a problem? Is this actually important?

I think so. I bet if you think about when you actually look at an email, it’s usually one of three times – when you first read it, as you write a reply to it, and when you’re searching for it later. In both of the second two cases, I’ve found that I often have more than one mail or thread that I want to look at while I write or do something in another app, and a dedicated view to support that would be great. I could search through just those messages. I could minimize or move them all at once. Just think of the possibilities!

Finally, if it’s easy to keep this set of emails around for later reference without cluttering up my screen in the meantime – and without actually moving the messages into some separate folder on my server – that’d be really great. Because you always have another expense report to file, and really, who wants to memorize that procedure?

Thanks for reading this far, and please feel free to leave a comment – am I missing something great in one of these clients?

I posted a few real articles there, then let things sit for a while as a dissertation, a new house, and a new baby have taken up my free time.

I’ve now decided to keep occasionally writing about email, just here at my good old personal blog. So I’ve imported the old posts from Tumblr, and anything new will be here. Hopefully having just one place for things will make it easier to actually write anything at all.

Thunderbird Conversations – GitHub.

From the screenshots, it looks pretty good. I downloaded it but lost energy after realizing that it’s only compatible with beta versions of Thunderbird 3.3. I have 3.0 or something, and the latest released version is 3.1, I guess. Or whatever.

Apple’s Mobile Me mail – a webmail that always struck me as trying too hard to be like a desktop mail client – has been re-designed, and it added two features that I completely agree with in a mail client – widescreen view (a message should be the entire height of a window) and a one-click archive button, to help achieve Inbox Zero as fast as possible.

Here’s a post from the recesses of memory.

Back in 2004, Brent Simmons said:

… your feedreader, like your browser and email app, is a hub of information. It makes sense to want to route information from the hub to other applications.

This is a great point – and I’d like to expand on it. I think it goes further than just being able to send data from your email client to other programs. Data should be easier to send in both directions.

Most email clients want to be your only interface to your mail data. Since email communication can affect everything we do on a workstation, every program should be able to look at and update your email store, even triggering checks or controlling how you are notified of new messages. What program is better able to determine what you’re likely focused on than the one you’re currently using?

The best way to handle this would involve some system-level support, so the largest set of applications could use it. I’m not holding my breath…

He talks about strategies for keeping an empty inbox based on processing email as it comes in, and deciding what to do with each message as you read it so nothing just sits there reminding you of vague, unspecified amounts of work you need to deal with sometime.

You may have to accept on faith that an empty inbox is a worthwhile goal. Some people disagree, but I think it’s safe to say that for most people, moving the things you get as email into more appropriate places like notes apps, calendars or to-do lists is a great way to get in control of your work. Process it, then get to work. I’ve been doing this for a while, and it’s a good feeling to know you don’t have any surprises laying forgotten in old mail.

One point from Merlin’s talk that I’d like to comment on is that email is just a medium, and it’s worth thinking about whether it’s really the best medium for what you’re trying to do. This has been in my mind lately as I’ve been working on a project with a series of parallel email-based heavily technical conversations, sometimes with three or four people replying every couple of minutes. I struggle with the feeling that email is just not the best way to do this, but it seems like the only way to include everyone.

Merlin made the point that sometimes email dysfunction is just a symptom of an organizational communications problem, and no amount of email system adjustment can solve it. I agree – if you’re really just tracking bugs, use a bug tracker. If you’re coordinating things in real time, use IMs or IRC. If you’re collaborating on a document, use something like Google Docs. Please stop overloading email.