Occasionally, I'm going to take a break from nit-picking existing mail clients to point to some interesting new ideas for email. It'll be focused on ideas you can use soon, that work with existing email standards - I'm going to hold off on talking about Google Wave until I understand what it's really for.

Today, there's Kwaga - they have a desktop app that shows you what's important in your inboxes. I haven't tried it, but from the website I can tell that they have a lot of good ideas about what might make an email important, and they're willing to spend some CPU cycles to figure it out.

It's basically a service that reads your mail, does some processing, and tells you if there's something you need to see - either it's important or it's a request of some kind, etc. The desktop app then links you back to the web client you use for mail, either GMail or Yahoo.

I love the idea of automated importance filtering - but I haven't tried it, because I dont like the fact that their server reads my email to do the filtering. If they have a desktop app, why not do that processing on the desktop? To be fair, they do say that the servers do not store the emails, and they're moving to OAuth for GMail, so they won't even store your passwords. But it still doesn't sit well, and promises like that won't fly at work.

Anyway, it looks like this kind of thing might be the closest most of us will get to having a personal assistant - so it's worth taking a look at. If anyone reading tries it, please let us know in the comments what you think.

Just something I noticed in Postbox just now - when I select a thread, it marks every message as read whether or not it was actually displayed.

This might be going down a rathole here, but I think I'd like read to mean that I've had the chance to see it…

I think the important thing here is separating "I'm done with this" from "Read" - which is not the way clients are written these days. Read should just be metadata. It's OK to archive things I haven't read.

Here's a set of screenshots that show how conversation view can help keeping up with a public list.

I've been subscribed to the LLVM-dev mailing list for years in GMail, and for about a week in my mikechecksmail test account. I'm not active in the LLVM project - it's just something I want to check in on occasionally. (For a while I had a filter that popped up any mention of Fortran). So when I check in, I want to skim the threads and read anything that's interesting. Usually that means I'm finding a thread that's already pretty long and I'm reading the whole thread from the beginning the first time I see it.

I'm interested to hear if that's not how you read public high-traffic lists - do you try to keep up with all the threads as they come in? I did that for a while, but it's hard to keep up with and probably isn't actually your job.

So, with that workflow in mind, how do our clients fare?

GMail

In GMail, when you click on a new thread (aka "conversation") you get the messages all on one page, starting with the earliest - perfect for reading from the beginning. This shot shows the first couple of messages in a medium size thread:

It's pretty good about handling quotes, too. If you're reading through an entire thread at a time, it's nice to have quoted text collapsed so you don't end up scrolling past the same paragraphs over and over. Of course, quoted text can be critical for understanding the new text:

- show quoted text -
Yes.

- show quoted text -
No!!

But in my judgement, barring some natural language analysis, the best default is to collapse and let the user click to expand quotes when necessary.

Finally, if you return to a thread and it has new messages, it'll collapse the ones you've seen before, handy to get a quick update:

Postbox

If you select "Show Conversations" in the "View" menu, Postbox shows something like a conversation-view when you select an entire thread. If you don't have that option on, or you select more than one message in any other way - like shift-or-command-clicking multiple messages, you get a blank content view. Not very useful, but a minor point - after all, GMail doesn't really show the list in the same page as the content anyway, so they've avoided that design problem.

The major problem with Postbox's conversation view - for this list-catchup task - is that it sorts the messages with the newest ones at the top. This is exactly the wrong thing for reading a whole thread, and I couldn't find a way to change this sort order.

Here's what it looks like on that same thread:

There are a couple other minor nitpicks - the info pane with the sender and links on the right-hand side only shows its info for the most recent message - if you want that info for another message, you have to select just that message in the list view.

If you revisit the thread, it marks every message as read, and there's no way to see what's new:

If you're still looking at the thread when new messages in that thread come in, it'll give you a nice alert and lets you refresh the view, but then the problem is still there - it's up to you to see what's new.

Thunderbird

Thunderbird 3 has a summary view, but it's not thread-centric. It just shows the sender, date and first few lines (smashed together without newlines) of each message you've selected. If you select a thread, it's kind of like a conversation view, but if you select multiple unrelated messages, it'll just show the messages in order.

Here's what that looks like:

Clearly there's some room for improvement there. I won't pick on it too much, except to say that smashing the text together for a summary makes this view basically useless.

Apple Mail

Apple Mail doesn't really try to give you a summary of a thread or a conversation view - it'll show which mails are new, but then you have to click through to an individual view of each message. Here's what it looks like:

This isn't sloppy like Thunderbird's view, but it's not very useful either. For this and other reasons, keeping up with public mailing lists in Apple Mail is pretty painful. That's why I moved most of my list subscriptions over to GMail a few years ago.

I've recently seen the concept of delight in software brought up in a couple different places, and I just wanted to cheer it on.

Jesper at waffle is starting an open-source web browser project to revive the spirit of OmniWeb, called rouse. He coins the phrase "delight innovation". I love that phrase. He's talking about taking a browser, something that's relatively stable, and looking for ways to make it noticeably better again. I love that impulse - it's something I'm hoping to see in email clients too.

Another place that delight showed up (along with Surprise and Joy), was at 52 weeks of UX in a post called "design for delight". That post seemed to be a little more about the parts of design that don't affect functionality, but do add personality. I really agree with this angle too - I like a program that has little details that are just for fun.

I'm signing up for a couple of public mailing lists to test how the clients help me handle the firehose of potentially-relevant emails.

For years now, I've used GMail exclusively for public lists, because the conversation view maps really well to how I like to scan most lists - I like to see what new threads have started, and only read individual messages if the topic is interesting. I also tend to look at a thread if someone smart has weighed in, so if a client helps me pick that out, it's good.

In GMail, it only shows three or so of the people in any thread, so I have resorted to filters that star any thread where smart people are talking. I don't love that solution, though, since I also use stars to manually flag something as important, and I'd rather not mix things up.

I've signed up for one low-traffic list (PyObjC-dev) and one higher-traffic list (LLVM-dev), since different traffic levels are different problems. A really high-traffic list can really test a client's filtering and thread display design.

Both of these lists are Mailman lists, which is a very broadly used system and it's what I'm used to. I'm open to hearing about other kinds of lists with different features that might change things, though - leave a comment.

For now I'm starting with digests off, which I like because I prefer to see things by thread instead of by date. Some clients do unpack digests automatically, so I might test that out sometime, but I think that a client should just control when it shows you bulk mail instead of just asking the list to only send it once a day.

I'll report here as the traffic builds and we'll see how each client handles it.

I've grabbed a copy of Postbox, so I can add it to the list of clients I'm poking around. It's cross-platform, based on Thunderbird, so it shares a lot of its foundations, such as a tabbed, multi-pane interface. The settings in particular are very similar to Thunderbird 3, with just the occasional tweak.

However, they've clearly put a lot of effort into a nice face-lift and some added features. Some of the features remind me of Chandler, such as the ability to quickly make a message into a 'todo', and to edit messages in place.

I'll be curious to see how many of these differences work. Editing messages in place doesn't seem like something I'm ever going to want to do, but I'd be interested to hear why someone else would.

They've also added twitter and facebook support, which I haven't investigated yet, but at first kind of goes against my email client religion - I'm not convinced that adding new protocols is the way to make clients better. However, there's definitely a growing feeling that we have too many inboxes now. That's a theme echoed in the Mozilla Raindrop project, too. So maybe this will appeal to people who want everything dumped into one program. For now, I'm not sold.

It's also one of the few clients you can actually pay for, which is interesting.

To revisit a couple of earlier topics, the unread count badge is the same as in Thunderbird 3 - no way to turn it off. (And they've kept the option to bounce and annoy on new mail. I didn't try it to see if it works.)

The model for allowing images in HTML mail is a small improvement on Thunderbird 3. You can allow it once, or just whitelist the sender - you will still get the sender as a full entry in your Contacts list, but it adds it quietly, without bugging you for the first name of Mr. Noreply. I guess I don't mind it as much, but contact list pollution still annoys me.

Here's a screenshot of Postbox telling me it's blocked some images. You can also see their 'todo' and 'edit' buttons - to turn the message into a todo or edit it in place, and the summary pane on the right side that shows some info about the sender and lists links and attachments.

In this screenshot, you can see it using that pane to list some attachments. However, what it's listing is attached images that are used inline in the HTML message. I'd prefer that it didn't treat those as first-class "attachments", even though they technically are.

Hi - Just a quick note that I added comments to this tumblog, so the six of us can have a nice chat about mail. You can also always trade thoughts with me at mikechecksmail at michael-mccracken.net.

Sincerely,

-mike

A little while ago I noticed the Mozilla Raindrop project. It's an interesting project in Mozilla Labs by the Thunderbird team.

It's trying to rethink how messaging (in general, not just email) should work - using open web technologies. On the surface it sounds like Google Wave, but I'd say it's aiming a little lower - trying to take existing protocols and build software that handles them all together in a better way. I also think it's a better approach than Wave, focusing on designing a single artifact that people will want to use instead of a framework technology demo, which is what Wave always seemed to me.

It looks like it's not intended to be a native desktop (or mobile) client - they mention running it on servers, and it depends on Python and CouchDB, which would preclude it running on the iPhone OS.

One of the things I like about it is the way they're trying to use a classification of emails - obviously, not all mails are equal. They fall somewhere in a range between spam and important personal (or work) messages. A big class is "bulk" mail - mail that's useful but not necessarily of a conversation involving you. Mailing lists, promotional mails you've asked for, facebook/twitter notifications might all fall into this category, and it's a great idea for a mailer to do something different with them. At the least, it should let you ignore them if you're just trying to do a quick processing pass of new mail.

The Raindrop design blog has some good posts (with plenty of screenshots) outlining their current approach.

[caption id="attachment_278" align="alignright" width="180" caption="The Workstation - RIP 2010?"][/caption]

Marco Arment wrote yesterday about mobile computing being more exciting than what he called "Desk" computing. I'm a fan of Marco's writing, and I usually agree with him, but that post got me thinking. I can't argue that mobile isn't exciting, but I disagree with his assertion that desktop computing is a solved problem. He's right that the pace of innovation has slowed. Certainly the last couple of OS X releases have fewer and fewer compelling differences. In fact, I'm writing this on OS X 10.5 -- 10.6 didn't impress me enough to make me bother upgrading.

Still, when Marco asks what I want out of 10.7, I think "what don't I want"?

I think there's tons of room to improve on and even rethink the workstation.

Maybe now that the consumer train has shifted toward more custom-designed tools for browsing, games, and social apps, there's room for workstation OSs to grow in ways that might improve them without worrying about leaving the home user behind (or boring them).

I'm not asking for unintuitive design. What I'm asking for is powerful tools - system and apps - for people who use computers for work every day. I certainly hope that these power tools will be built with elegance and style. I'm not asking for dual cameras and four speakers.

Market forces have limited development of crucial daily-use work tools to what will appeal to the home & leisure market. For instance, Apple ships Mail and iCal with the OS. Both are fine programs, but are clearly trying to ride the line between work features such as meeting planning, and consumer features like stationery. Meanwhile, the market for alternatives is limited, and even some of the alternatives have taken the approach of adding consumer-related features. Postbox, for instance, has added facebook and twitter support. That's not helping me get work done - quite the opposite, really.

But am I really just talking about incremental improvements and a few more work-oriented features here and there? I don't think so. To be more specific about what kind of big improvements I think are possible in desktop systems, I did a few minutes of brainstorming. Here's what I came up with:

Like the personal jetpack, I'm still waiting for the system that knows what I'm trying to do and co-ordinates to help me get it done. The one that learns (even crudely!) about my habits and the time of day, my colleagues, their schedules, etc. The one with this knowledge baked in everywhere in the system. For instance, it knows which app's notifications can be ignored for later.

As a start, I'd even settle for a single system that actually uses all the good ideas that have come up in the past 30 years. Let's at least catch up to Douglas Engelbart's vision of the NLS system for augmenting collective knowledge work before we call it a day.

Good search everywhere has been a real improvement, but what about full support for smart annotations for files, events, people and other data? The BeOS file system comes to mind. Search is better when there's better info to search for. If I push it a little, some smart background prediction of categories for documents that'd help me find them later -- that couldn't hurt. Why doesn't a file know who emailed it to me?

Another blast from the past - maybe OpenDoc was a stretch, but more open document formats and easier flowing data between applications isn't a bad idea - can we expand on that?

This one ties in with mobile devices - Real, honest to god multi-computer network syncing. It can be done - it should be baked in! What if your filesystem was actually an easily merge-able version-controlled document oriented database like CouchDB? Can we use some ideas from distributed version control to make sharing documents on disconnected filesystems work right automatically? I still think the best solution doesn't depend on storing everything on servers (especially public servers).

That leads to the oft-repeated idea of getting rid of "saving". I shouldn't have to commit changes - maybe I want to tag a version, but the data should always be written to disk.

Every app should be able to know about communication (mail, IM, SMS, whatever) that might affect what you're working on in it. Today's apps have uniform access to your files - but not to your messages. This seems like a bad historical distinction - they're both relevant data. For example, why do I have to "save attachments"? It's already on my disk…

What about application and system scripting that really works - that's easy enough for quick things but powerful and fast enough to grow a real program from? Let me start them as visual or spoken one-off commands but then edit and share them as text.

System support for Quicksilver/Launchbar/Ubiquity-style text command lines. Tie this into the scripting system. Make it feel like I tell the computer what to do instead of finding the right app to tell, opening it, etc.

System-wide hypertext - I should be able to create robust links between document parts, messages, people, and other entities. It should be fast to view an annotated list of changes across versions of a document, showing who did them and what they said about it in emails. This shouldn't have to all reside on some central server to work.

Do you have any ideas to add to the list?

Apple Mail's "Send again" feature is handy - it takes a message and creates a duplicate of it, ready to either edit or re-send exactly as-is. It's a bit of a mystery, though, and I bet it isn't used much.

The problem is that the wording and keyboard shortcut don't say enough about what's really about to happen. You could be forgiven for guessing that since ⌘-D sends new mails out onto the wire, it'll just send the old mail - unedited - out on the wire, too. There's no hint that you get to edit it.

There's also the possibility for error, since pressing ⌘-D once gives you a new mail with the old contents, which a second ⌘-D will send right away, with no undo. (Lack of undo in sending is a topic for another post, of course)

Also unexpected because of the name, the message doesn't have to be one you sent. If you invoke "Send again" on a message you received, you'll get a new message with the same recipients, from you. I'm having a hard time imagining why I'd ever use this. Maybe it'd save a copy and paste when sending a copy of something that I don't want to just forward, but that's a stretch. How often does that happen?

It's a handy feature, but it needs a better name and a better shortcut.

Why is it handy? Sometimes I write a draft of an email to the outside world, then send it to team members for review. Then later, I want to edit that draft, incorporate their suggestions and send it off anew. That's when I use "Send again". But I only discovered it by accident.

Despite this use case, this seems like a feature that probably isn't worth the effort and extra UI clutter.