(Cross-posted from http://evilbrainjono.net)

I wrote a Thunderbird add-on to make the email interface I’ve always wanted — one that helps me remember to stay in touch with people I really care about, instead of always distracting me with the newest incoming trivia.

The add-on is called Lovebird and you can download it here.

lovebird screenshot (with fake names)

the names in this screenshot have been changed to protect the innocent

The rest of this post is about the philosophy behind Lovebird and why I designed it the way I did.

(more…)

A modal dialog box is the software designer making a claim that the software cannot do anything else until the user makes a decision. Upon closer examination, this claim is almost never justified. It’s usually a case of developer arrogance: developers assuming that because they have to care about some edge case in the software control flow, the user should have to care about it too.

There’s a particularly egregious example in Thunderbird 7.0 which I’ve seen a lot of lately because I’ve been composing a lot of emails offline.

I’ll be on the train or something, happily offline, typing an email in Thunderbird for later sending, and suddenly I’m interrupted by this:

Modal dialog box asking whether to retry saving a draft

Email composition, interrupted. Train of thought, destroyed. Input window, blocked. I cannot continue until I’ve processed what the software is asking me and made a decision.

Alright, Thunderbird, what’s the problem? Oh, you couldn’t save my draft to my mail server? Gee, I wonder why. Maybe because I’m not connected to the internet. There’s no reason I would expect you to be able to save a draft right now.

The correct behavior would be for Thunderbird to keep checking, silently, for an internet connection, and to save the draft to the server as soon as a connection becomes available again. But there’s no button for that, so I click “Cancel”.

Warning message telling me that the draft could not be saved

Argh! Another one! What is it this time?

…An error message telling me my draft could not be saved. Thunderbird, I just told you to stop trying to save my draft. Why are you using an error message to report that you’re doing as I told you? That’s not an error, that’s the expected result of the button I just clicked. Why are you telling me anything at all? Why are you putting another dialog box in my way instead of just letting me get back to my email?

Jef Raskin used to call these “Monolog boxes” — they’re like dialog boxes except there’s no dialogue because the software isn’t asking me for any information. It’s just complaining to me and then making me click a button to acknowledge that I heard its complaint.

So that’s a modal dialog box followed by a modal monolog box just to tell me something I already knew, which is that I’m offline so of course drafts can’t be saved. And this pointless ritual recurs every ten minutes or so when Thunderbird tries to save my draft. If I’m composing multiple emails at the same time, I have to dismiss these pointless dialogs for every composition window!

The way to fix this interface is quite simple. There’s no reason to interrupt the user to report on the status of saving the draft. Thunderbird should allow me to keep typing my email while it displays a discreet warning message — off in the corner of the window, perhaps — to the effect of “This draft has not been backed up.” Even that much is arguably unnecessary, because the right thing to do in this case is obvious: back up the draft to my hard drive, and then sync it to my email server when an internet connection becomes available again. This can be done without any user input at all.

When the right thing to do is obvious, software should just quietly do it. It shouldn’t interrupt me to ask my permission or complain about problems.

The way the “reply-all” button works in Thunderbird is noticably worse than the way it works in GMail.

The difference might seem trivial, but the GMail version saves me a lot of aggravation, because the following scenario happens at least twice a day:

I hit “reply” and start writing an email. A few sentences in, I discover that the message I’m writing applies to all the people in the original thread, not just the sender. I want to change my “reply” to a “reply all”.

In GMail if I hit “reply all”, it does the right thing: adds the addresses of the other people on the thread to my composition already in progress.

Screenshot of reply-all button in GMail

In Thunderbird (as of version 7.0.1), the Reply and Reply All buttons spawn new windows. If I switch from a “Reply” composition window back to the main window and hit “Reply All”, I get a brand-new composition window. To save what I’ve already written, I have to copy-paste my words from the original window to the new one, then close the first window.

Screenshot of Thunderbird's reply-all button

It’s just a few extra steps, but it’s annoying in a way that disrupts my train of thought, which should be focused on the content of my writing, not the mechanics of sending it.

It would be nice to get the GMail reply-all behavior in Thunderbird. But it would be even nicer if designers everywhere could more consistently embrace the design principle behind the GMail reply-all button. That principle is:

Let me change my mind without having to start over.

We need to recognize that humans change their minds about what they want all the time. If I’m on Step Four and I realize I should have gone right instead of left at Step One, I should not have to re-enter the same information for Steps Two and Three. And yet too many interfaces (I’m thinking multi-stage web forms, “setup wizards”, and the like) still force users to make decisions in an arbitrary sequence dictated by the implementation details of the code.

Doing it right is more work for the programmer, of course. The implementation must be more complex. You can't simplify by throwing away data related to paths not immediately taken. But respecting the reality that users change their minds is more important than cutting corners in your code.

Thunderbird dock icon showing 14875 unread emails

See that? That is the Thunderbird dock icon on Mac OS X. It shows the number of unread emails you have.

What looks like “1487!” is actually “14875” with part of the “5” cut off. I have discovered the dock icon can’t display 5-digit numbers correctly! A bug!

Hm. Perhaps this is the rare case where it is, in fact, the user’s fault for having 14875 unread emails. What should Thunderbird do when you get to five digits? At this point the exact number is not particularly informative. Maybe when you get to 5 digits, it should just show an infinity symbol. Or a sign that says “You’re screwed”. Or a link to inboxzero.

Congratulations to Mozilla Messaging for finally finishing Thunderbird 3! In honor of last week’s Thunderbird 3.0 release, I’d like to do a series of blog posts on my experience migrating from GMail to Thunderbird over the past couple months.

Don’t get me wrong, I love a lot of things about GMail. Treating the conversation, instead of the individual message, as the basic object was a big step forward in e-mail interfaces. Good, fast search plus vast disk space changed the way I think about my email archives.

However, this October I ran into some problems with GMail. I had set myself up both to receive email sent to my mozilla.com address in my GMail inbox and also to be able to send from my mozilla.com address through the GMail interface. Although it had the minor drawback of mixing my work and private lives together in a single extremely busy inbox, that seemed like a fair price for the increased convenience.

In October, though, I realized that some of my coworkers hadn’t been getting emails from me. It took me a while to notice: I thought everyone was just too busy to respond to what I had written. But by asking a few people to search their inboxes for mail from me, I confirmed a hunch – most of the mail I had sent from my mozilla.com address through the GMail interface over a period of a couple of weeks had not been delivered. It hadn’t gone to their spam folders, either – it had just silently disappeared.

Everything had been working fine up until October, so what happened? I’m still not exactly sure. One theory is that my Mozilla mail was being sent through gmail.com, but the “from” address said “mozilla.com”. A “from” address that doesn’t match the sending server is a common sign of spam, so maybe a change in spam-filtering policy made our relay servers start throwing out my messages. On the other hand, maybe it had to do with me changing my Mozilla LDAP password, and not remembering it to update the password stored in my GMail settings for the external account.

Either way, it was the worst kind of software failure: the silent kind! Because GMail’s interface reported that the messages had been sent, I never stopped to think that maybe they hadn’t. It’s easy to forget that email was never designed to be a highly reliable protocol. Sometimes you get bounce messages back when something goes wrong, but it’s never guaranteed.

So I don’t particularly blame GMail for what happened. It would have been nice to get more notification, but the problem was really outside of their knowledge or control; I was expecting too much from a web application. It is in the nature of a web application that the user gives up a certain amount of control in exchange for convenience. Often a good trade. But for something as personal and essential as my email? My experience with the lost messages drove home the price of not having that control.

Besides, it was about time I started eating Mozilla’s own dogfood for my email.

I’ve been keeping a notes file on my transition to Thunderbird. In my next few posts I want to share with you some of its pros and cons, tips for using it effectively, things that are cool about its interface and things that could use improvement.

Several computer science students at the University of Toronto and Seneca have made it their class project for this semester to port Ubiquity to Thunderbird and make it run there. Thanks to their efforts so far, we now have the basic functionality operational, as you can see in the screenshot below:

Don’t get too excited yet. This is still in the early prototype phase. Currently the hotkey works, the parser works, the previews mostly work, and a few commands work when executed, but most don’t. The students have to turn in their project at the end of the 2008 fall semester, so if all goes well perhaps we’ll have a usable Thunderbird extension sometime in December.

But it’s not to early to start thinking about the possibilities, such as:

  • Using existing ubiquity commands, like map and translate and whatever your favorite third-party commands are, while reading and writing emails in Thunderbird.
  • Cross-application functionality: email commands activated from Firefox could execute using Thunderbird, while web-searching and social-networking commands used from Thunderbird could execute using Firefox.
  • Sharing of data sources for argument suggestions: for example, the “email” command could use your Thunderbird contact list to autocomplete the recipient’s address, no matter where the command is used from.
  • Brand-new Ubiquity commands for searching and sorting through your email, composing, redirecting, creating filters, and so on.
  • Allowing everybody in the world to create and share email commands, encouraging massive innovation to discover new ways of coping with the Never-Ending Email Flood.

I think ultimately we’re going to have a single cross-compatible XPI that can be installed both on Firefox and on Thunderbird, but for now we’ve made a temporary fork and are doing Ubiq-Tbird development in a separate repository at http://hg.toolness.com/ubiquity-thunderbird. If you want to get the source code and set it up to run in your copy of Thunderbird, a page of very rough documentation is here on the wiki.

Once Ubiquity is fully operational in Thunderbird, what would you like to be able to do with it? Do you have any ideas for commands that you’d especially like to have to help keep your inbox under control? Leave a comment and talk about what you’d like to see!