Features/Thunderbird/Instant messaging in Thunderbird
Status
Instant messaging in Thunderbird | |
Stage | Shipped |
Status | In progress |
Release target | Thunderbird 15 |
Health | OK |
Status note | Landed for Thunderbird 13 but pref'ed off for Tb 13 and Tb 14 (about:config->mail.chat.enabled). Released pref'ed on in Tb 15. |
Team
Product manager | Florian Quèze |
Directly Responsible Individual | ` |
Lead engineer | ` |
Security lead | Paul Theriault |
Privacy lead | ` |
Localization lead | ` |
Accessibility lead | ` |
QA lead | ` |
UX lead | ` |
Product marketing lead | ` |
Operations lead | ` |
Additional members | ` |
Open issues/risks
See the discussion page for a summary of questions that were discussed while this page was a draft and answers that were gathered.
Stage 1: Definition
1. Feature overview
The goal is to bring additional value to Thunderbird users by leveraging instant messaging communications. In other words, to enrich the email experience with instant messaging functionality.
2. Users & use cases
Targeted users are people who use Thunderbird for their emails and may IM the same set of contacts.
Presence information
- Seeing that the sender of an email is online can help decide an IM conversation will be better than an email reply.
Unifying data storage
- All contact information handled in a single place
- All archives searchable in a single place: this removes for the user the burden of remembering which communication medium was used.
Leveraging links between IM conversations and emails
- Keeping links between emails and the related IM conversations can simplify further processing of the exchanges:
- when rereading the whole discussion
- when forwarding it
- A link can either be strong, when it comes from an explicit user action (eg. the user started a chat from the presence info of an email header) or weak if Thunderbird assumed it (eg. an IM conversation happened between 2 emails with the same people involved).
- Accessing the list of recently exchanged emails when a chat begins can save time:
- if the user was about to ask a question that's already answered in an unread email
- if the contact starting the chat is following up to a recent email
(See also the "How can this bring additional value for users?" question on the discussion page for some related discussion and a few possible future use cases).
3. Dependencies
-
Address book updates to support IM addresses for different networks (?) -
Composing in a tab, so that potential IM activity indicators placed in the main UI stay visible. (?)
4. Requirements
- IM right from Thunderbird
- Manage contacts for email and IM in a single place.
- Search both Email and IM archives at once.
- Keep track of links between related emails and IM conversations.
Non-goals
- Turn Thunderbird into an IM client for people who don't want to use it for their emails.
- Support as many IM protocols as possible: For a first version with IM features included, we want to focus first on a good UI integration between email and IM features. Support for more protocols can come later.
Stage 2: Design
5. Functional specification
General IM UI
- IM features should be tightly integrated into the Thunderbird UI, so that they don't feel like something added after the fact.
- Presence information, when available, should be provided wherever some contact information appears (headers of emails, message lists, email compose UI, ...).
- IM features shouldn't get in the way of users interacting with their emails.
- Users who only want an email client should never see the IM UI if they don't configure any IM account.
- It should be easy to change one's IM status or even to sign off from all IM accounts, to avoid interruptions / revealing presence.
- Ongoing IM conversations should have visible indicators in the primary Thunderbird UI but they shouldn't hinder the user's ability to focus on his current task (reading an email / composing a reply / ...)
- More specifically, new unread messages should be notified unobtrusively to the user.
IM networks/protocol support
- Thunderbird will support by default only a few IM protocols
- XMPP is a good first candidate:
- it's an open standard
- it gives access to some quite popular IM networks (Google Talk, Facebook Chat).
- IRC and Twitter are also interesting candidates (they can come later though):
- they are open (or at least documented)
- they are widely used in the Mozilla community
- the user interactions are significantly different from those with XMPP, which will force us to iron out some UI integration issues that may be unnoticed with XMPP.
- XMPP is a good first candidate:
- A plugin system should let users add support for more protocols (even closed protocols) with add-ons.
IM accounts management
- The 'Account Settings...' dialog should let users configure settings of their IM accounts.
- An 'Add Instant Messaging Account...' menu item lets the user open a wizard to set up an IM account.
- no longer planned for the first version shipping with IM:
While setting up an email account, Thunderbird will attempt to detect if an IM account is likely associated with the email account (@gmail.com address? Existence of DNS SRV records pointing to an XMPP server for the domain?).-
If an IM account is found, the default action would be to configure Thunderbird to use it. -
It should be possible to opt-out from this behavior (checkbox "also use this account for instant messaging", checked by default?)
-
Address book integration
- Address book cards will support multiple IM contact info for each contact.
- Whenever possible, IM contacts will be associated with email contacts automatically.
- Users will also be able to add associations between IM and email contacts by hand.
Archives
- IM conversations should be stored in the profile, so that the user can use the transcripts for future references
- Stored conversations should be indexed in a way that makes searching both the email and IM archives at once efficient.
- The search results should show IMs alongside emails.
- It should be possible to turn off archiving of IMs or to keep them only for a limited period of time, in order to comply with some data retention policies companies may have.
6. User experience design
- Account management: the account wizard will be (almost?) the same as the Instantbird account wizard. IM account settings will be configured from the current Thunderbird Account Settings dialog.
- Address book integration: fields for adding an arbitrary number of IM contact information per address book card will be added.
- Conversations will be presented in a separate top level "Chat" tab composed of 3 panes: a list of available contacts/ongoing conversation on the left pane, the conversation content in the middle pane, and some context information (contact information, summary of previous interactions with the contact, ...) in a right pane.
- Selection of the current IM status: still being discussed
- Adding IM contacts: (still being discussed) We feel that adding IM contact information in the address book is not the same action as adding an IM contact to the contact list of an IM account, so we need some UI specifically to add contacts to the IM accounts.
- Preferences: a "Chat" pane can be added to the current Thunderbird pref window, offering a relevant subset of the preferences that Instantbird's prefwindow offers.
Stage 3: Planning
7. Implementation plan
To move forward quickly, the most practicable plan is to put Instantbird's code into a Thunderbird build, and then iterate to remove what can't be shipped (GPL'ed code) and improve the integration.
Main tasks:
- remove the dependency of the IM core of Instantbird on libpurple. (almost done, work tracked in Instantbird bug 759)
- integrate more protocol plugins implemented in JavaScript.
- Instantbird 1.0 and 1.1 shipped with only Twitter implemented in JavaScript.
- An XMPP implementation in JS has been developed this summer by a Google Summer of Code student. (currently being reviewed in Instantbird bug 1171)
- An IRC implementation in JS has been developed by an Instantbird developer. (needs a review, tracked in Instantbird bug 507)
- conversation logs should be written in an easily parsable format (best candidate seems JSON), and indexed in gloda.
- integration into the current address book
- UI integration, the current plan, designed so that we can try a working prototype as soon as possible, is roughly:
- start by the changes needed so that IM accounts can be added/configured
- then add the UI where conversations can happen
- finally, iterate on other integration points and polish details until we are satisfied.
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
Tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=714733
Stage 5: Release
10. Landing criteria
`
Feature details
Priority | P1 |
Rank | 100 |
Theme / Goal | ` |
Roadmap | Thunderbird |
Secondary roadmap | ` |
Feature list | Thunderbird |
Project | ` |
Engineering team | Thunderbird |
Team status notes
status | notes | |
Products | ` | ` |
Engineering | ` | ` |
Security | sec-review-complete | Notes |
Privacy | ` | ` |
Localization | ` | ` |
Accessibility | ` | ` |
Quality assurance | ` | ` |
User experience | ` | ` |
Product marketing | ` | ` |
Operations | ` | ` |