Thunderbird:Rage Against The Account Machine

From MozillaWiki
Jump to: navigation, search

The system of accounts in Thunderbird 2.0.0.x suffers from serious usability problems. (In common parlance, the system sucks.) This memo, Rage Against The Account Machine, proposes the elimination of Thunderbird accounts as we know them.

The problems

The system of accounts in Thunderbird 2.0.0.x interrupts the user, prevents use and exploration of Thunderbird, requires extensive knowledge of technical details, and binds together settings that are not necessarily related to each other.

Interrupting the user

In typical scenarios, the user’s first experience in using Thunderbird 2.0.0.x is that Thunderbird demands that the user create and configure an account before doing anything else. Suppose that the user needs to express a thought in writing before the thought slips from the user’s mind, or suppose a similar scenario. Thunderbird 2.0.0.x makes the user jump through hoops just to begin writing a note.

Preventing use and exploration

If the user declines to jump through hoops, Thunderbird 2.0.0.x quits. There is, then, no possibility of exploring Thunderbird 2.0.0.x. Whatever beneficial features and interfaces Thunderbird 2.0.0.x might have, the user cannot find them until complying with Thunderbird’s demands. Presented with what is, essentially, the hostility of “my way or the highway”, too many users will choose the highway.

Requiring extensive knowledge

Many users and still more potential users don’t have a clue about the settings required for sending and receiving mail. POP3, IMAP, NNTP, SMTP, LDAP, STARTTLS, ports, secure authentication, local folders, global inbox – what are these and why do they matter? Asking the user to consult documentation or to get answers from technical support is a high barrier to entry. The user shouldn’t need to know this stuff.

Binding unrelated settings

Thunderbird 2.0.0.x binds settings for disparate and possibly orthogonal things. (While it is possible to edit files [with [about:config], for instance] to configure these settings in a more compact or convenient way, Thunderbird should not force users to such lengths in order to achieve basic goals.) Granted, there are reasons to relate all or some of originators’ names, originators’ addresses, originators’ affiliations (“Organization” header fields), conversational directives (“Reply-To” header fields), signatures, composition preferences (plain text, HTML), storage directives (for incoming, outgoing, and draft messages), mailbox servers (POP, IMAP), and mail exchange servers (SMTP). Yet Thunderbird 2.0.0.x requires the relation of these things, and, by default, relates these things in a rigid way (as by partitioning the set of identities by account). This is neither convenient nor necessary.

The solution

Most of the solution becomes obvious when we identify and understand the problems with the system of accounts in Thunderbird 2.0.0.x. The user deserves immediate access to all or most features and interfaces of the application, the freedom to enter addresses of the originators of a message while composing that message, the freedom to enter signatures while composing messages, the ability to send mail without explicit configuration of the delivery parameters, the ability to receive mail without explicit configuration of the reception parameters., automatic recording of the various addresses and parameters that the user enters, simple presentation of that information, the ability to ignore details of message storage, and the ability to group various settings according to need and convenience.

Immediate access to Thunderbird

The crucial step is to get rid of the initial account-configuration dialog. If the user got to Thunderbird by following a link with a “mailto” URI, let the user write a message without interruption. Let the user see the application, its features, and its settings.

Entering originator addresses when composing messages

When the user composes a message, Thunderbird should treat the “From” header field like Thunderbird treats the “To” header field. That is, the user should have the freedom to enter an arbitrary name and address, and then to add more names and addresses. Free entry overcomes the need to gather name and address before composing messages.

For suggestions to the user, Thunderbird should look at the usual suspects for the user’s name and address: registry settings for Outlook and Outlook Express on Microsoft Windows, the user’s vCard on Mac OS X and on Microsoft Windows Vista.

Entering signatures when composing messages

When the user composes a message, Thunderbird should provide an opportunity to create and enter signatures. Something like a text-entry field, separate from the main field for the message body, disabled by default and enabled through a checkbox, would allow the user to write a signature or to choose from existing signatures.

Sending and receiving mail without user configuration

Given the user’s e-mail address and being able to detect the user’s Internet Protocol address (IP address), Thunderbird should identify an appropriate SMTP server through mechanisms like the Domain Name System and configuration files specific to Internet-service providers (ISP files). The exact process is out of scope for this memo, but see DNS-based lookup and Autoconfiguration for proposals. Thunderbird should prompt the user for server details only as a last resort, and, even then, should be unobtrusive, prompting the user in something like the non-modal infobar in Firefox.

Recording information

As the user enters names, e-mail addresses, server names, signatures, and other information, Thunderbird should record these data and store them as suggestions for later entries. This is analogous to the current functionality embodied in the “Collected Addresses” addressbook.

Presenting recorded information

Thunderbird should search its stores of data and use a scoring system, something like the so-called frecency (frequency/recency score) in Firefox 3, to suggest entries for various fields. For instance, as the user enters text in the “From” field, Thunderbird should show matching entries from past messages and should prioritize past “From” entries over other entries.

Unifying message storage

Having a single database to store all messages would free the user from the need to think about the details of storage. The functionality that Thunderbird 2.0.0.x provides through mail folders is something that a Thunderbird with a unified database of messages could provide through SQL (or something similar).

Allowing groups of preferences

In recognition that there are circumstances that warrant binding settings into groups, Thunderbird should make the process easy. Recognizing that no rules of combination will suit all users, Thunderbird should make the process flexible.

Problems that this proposal raises

As with all innovations, the proposal in this memo has its problems.

Maildir access

It is clear that some users want to use Thunderbird to access maildir messages stores. Thunderbird should accomodate this desire. However, separate message stores do not fit neatly in the paradigm of a unified message store. Perhaps a configuration of settings, each given a place in the preferences chrome, would direct Thunderbird to use a maildir message store in addition to or instead of Thunderbird’s default message store.

The “Sender” header field

Conformance to Internet standards (and draft standards and proposed standards) requires that Thunderbird, if allowing multiple mailbox addresses in the “From” header field, provide a single mailbox address in the “Sender” header field. A technique to consider is to add a “Sender” header field in the graphical user interface and in the underlying message whenever the user enters more than one address in the “From” header field. Thunderbird would populate the “Sender” header field with the first mailbox address in the “From” header field and would allow the user to change the entry at will.

Related work


Etan Wexler is the original author of Rage Against The Account Machine.


This work would not have been possible without the inspirational music of DJs Adrian and the Mysterious D (A+D). (Coincidentally, A+D manage and spin at the Bootie parties that take place in the DNA Lounge, a venture of one Jamie Zawinski, better known to the Mozilla community as a Netscape employee who worked extensively on the mail and news parts of Mozilla.)