Features/Thunderbird/Instant messaging in Thunderbird

Please use "Edit with form" above to edit this page.

Status

Instant messaging in Thunderbird
Stage	Draft
Status	In progress
Release target	`
Health	OK
Status note	`

{{#set:Feature name=Instant messaging in Thunderbird

|Feature stage=Draft |Feature status=In progress |Feature version=` |Feature health=OK |Feature status note=` }}

Team

Product manager	Florian Quèze
Directly Responsible Individual	`
Lead engineer	`
Security lead	`
Privacy lead	`
Localization lead	`
Accessibility lead	`
QA lead	`
UX lead	`
Product marketing lead	`
Operations lead	`
Additional members	`

{{#set:Feature product manager=Florian Quèze

|Feature feature manager=` |Feature lead engineer=` |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}

Open issues/risks

Some points that are still completely open to discussion but need a decision before or as part of the "Design" stage here:

• Should IM conversations happen inside Thunderbird (removing the need for the user to have another IM client on his system), or should they happen in the user's default IM client (like http links are viewed in the default web browser)? (In the first case, Thunderbird would connect directly to IM servers through IM protocols, on the second case, Thunderbird would integrate with the IM software installed on the local system to share data.)
  • Using the default IM client seems like a false good idea because:
    • It appears like it would save implementation time and help us ship something sooner... but if we end up having to ship our own stack later, integrating with the default clients first is a waste of time/resources.
    • There's no guarantee that the clients we would like to integrate with (the clients with significant usage from our target users) provide useful APIs.
    • Possible security / privacy issues: we can't offer any guarantee on the way IM conversation data is handled locally and transfered over the network by third party IM clients.
  • Integrating some protocol implementations by default doesn't dispense us from having a plugin system for protocol which, by their closed nature, can't be implemented directly (obvious example: Skype).

• Should IMs go above the current content (the emails the user is reading or the email he is composing) or be contained in some specific area (tab? folder? other window?) where the user would have to go to exchange IMs.
  • Showing IMs above may be interrupting/distracting.
  • IMs may go unnoticed if they aren't visible enough, and lose the benefit of "instantness" that IM has compared to email.
  • (Gmail shows IMs above emails.)
  • Users should be able to see easily if someone is waiting for a reply? (IM) or if it's probably OK to think for a few hours about the message's content before replying (email)

• What's the scope of "instant messaging"?
  • In this context, IM may extend to social network communications, or even to telephony or anything providing a more "instant" communication than email.
  • Should we include social networks (like twitter/facebook/...)?
    • If we include a small subset of the features people are used to having in a twitter client, there's a risk of that feature set to be too small to be actually useful.
  • Which networks of "instant" communication make sense here?
    • Probably depends on what the users we target need or already use: some corporate users may need access to private IM networks (Sametime, GroupWise, Office Communicator
    • Need some user research.
  • Where do we start?
    • Instantbird has JS (MPL-trilicensed) code for twitter and soon for XMPP and IRC.
    • Lots of closed protocols can be supported through libpurple; however libpurple is GPLed so we can't ship libpurple plugins by default, they would have to be add-ons.
    • We may want to promote open standards, which are better aligned with the Mozilla Manifesto.
    • Supporting the XMPP protocol (giving access to the Google Talk and Facebook Chat networks), IRC and maybe Twitter would be enough to experiment with the UI; we can add support for more networks later.

• Who are the target users?
  • People already using both Thunderbird and some other IM software?
    • Should we detect already configured email accounts that are likely also usable for IM? (@gmail.com, @aol.com, @hotmail, ...)
  • Thunderbird users without IM account/experience?
    • Should we offer to create an account during the first startup?
  • People using competing software that already integrates email and IM (Gmail website, Outlook+Office Communicator, ...)?

• What's the minimum viable product?
  • Seeing if the sender of an email is online and being able to click to start an IM conversation in the system default chat client?
    • If centralizing all the user's communication in a single application is a goal, then it's not enough.
  • Providing a reliable offline archive of all messages exchanged on some networks? (for example a read-only copy of all twitter messages)
    • Need user research to know which networks matter.
  • The short term goals we pick need to be compatible with the long term vision.
    • Is it OK to rely on other IM clients of the system if we intend to develop a mobile version later?
    • If we want to help users to "own" their data by regrouping all the communication data in a single place where it's easy to manage, is it acceptable to delegate communication tasks to external applications? (shouldn't we have control over encryption? are there potential privacy issues?)

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.

Additional value should come from bringing IM features closer to Thunderbird, for example:

• Seeing that the sender of an email is available to chat may lead the user to decide an IM conversation is better to get some clarification about some points of the email he was reading.
  • Then the IM conversation could be somehow "attached" to the email. The conversation could annotate the email, so that searching the archives for the email also brings up the IM comments.
• When a user is about to start an IM conversation with a contact, showing the list of exchanged emails with this person could avoid wasting time for both people (maybe the desired information is right there in the bulk of unread emails? Maybe the latest email explains why the person wouldn't be able to give a useful answer anyway? ...)
• When trying to get back to some piece of information obtained in the past from someone, searching in both email and IM archives removes for the user the burden of remembering which communication medium was used.
• Forwarding (parts of) an IM conversation should be easier if the IM conversation is reachable directly from Thunderbird.
• If emails are shown in a conversation view, integrating in that view the IM conversations that happened on the same subject could give a better overview of the exchanges.
• (assuming calendar integration) While setting up an event, seeing that some of the invitees are online and starting an IM conversation with them could help discuss and find a possible date/time faster.
• Collaborative editing: asking someone who's available to proof read an email draft, and discussing the proposed changes in an IM conversation.

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

• Manage contacts for email and IM in a single place.
• Search both Email and IM archives at once.

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

(at this point the content of this section is a draft, still open to discussion)

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 are open (or at least documented)
    • they are widely used in the Mozilla comunity
    • the user interactions are significantly different from those with XMPP, which will force us to iron out some UI integration issues that may be unoticed with XMPP.
• A plugin system should let users add support for more protocols (even closed protocols) with add-ons.

IM accounts management

• 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? Existance 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?)
• The 'Add Other Account...' wizard should offer a way to set up an IM account manually.
• The 'Account Settings...' dialog should let users configure settings of their IM accounts.

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.

General IM UI

• IM features shouldn't get in the way of users interacting with their emails.
  • 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 features should be tightly integrated into the Thunderbird UI, so that they don't feel like something added after the fact.

Archives

• IM conversations should be stored, 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.

6. User experience design

`

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=Some points that are still completely open to discussion but need a decision before or as part of the "Design" stage here:

• Should IM conversations happen inside Thunderbird (removing the need for the user to have another IM client on his system), or should they happen in the user's default IM client (like http links are viewed in the default web browser)? (In the first case, Thunderbird would connect directly to IM servers through IM protocols, on the second case, Thunderbird would integrate with the IM software installed on the local system to share data.)
  • Using the default IM client seems like a false good idea because:
    • It appears like it would save implementation time and help us ship something sooner... but if we end up having to ship our own stack later, integrating with the default clients first is a waste of time/resources.
    • There's no guarantee that the clients we would like to integrate with (the clients with significant usage from our target users) provide useful APIs.
    • Possible security / privacy issues: we can't offer any guarantee on the way IM conversation data is handled locally and transfered over the network by third party IM clients.
  • Integrating some protocol implementations by default doesn't dispense us from having a plugin system for protocol which, by their closed nature, can't be implemented directly (obvious example: Skype).

• Should IMs go above the current content (the emails the user is reading or the email he is composing) or be contained in some specific area (tab? folder? other window?) where the user would have to go to exchange IMs.
  • Showing IMs above may be interrupting/distracting.
  • IMs may go unnoticed if they aren't visible enough, and lose the benefit of "instantness" that IM has compared to email.
  • (Gmail shows IMs above emails.)
  • Users should be able to see easily if someone is waiting for a reply? (IM) or if it's probably OK to think for a few hours about the message's content before replying (email)

• What's the scope of "instant messaging"?
  • In this context, IM may extend to social network communications, or even to telephony or anything providing a more "instant" communication than email.
  • Should we include social networks (like twitter/facebook/...)?
    • If we include a small subset of the features people are used to having in a twitter client, there's a risk of that feature set to be too small to be actually useful.
  • Which networks of "instant" communication make sense here?
    • Probably depends on what the users we target need or already use: some corporate users may need access to private IM networks (Sametime, GroupWise, Office Communicator
    • Need some user research.
  • Where do we start?
    • Instantbird has JS (MPL-trilicensed) code for twitter and soon for XMPP and IRC.
    • Lots of closed protocols can be supported through libpurple; however libpurple is GPLed so we can't ship libpurple plugins by default, they would have to be add-ons.
    • We may want to promote open standards, which are better aligned with the Mozilla Manifesto.
    • Supporting the XMPP protocol (giving access to the Google Talk and Facebook Chat networks), IRC and maybe Twitter would be enough to experiment with the UI; we can add support for more networks later.

• Who are the target users?
  • People already using both Thunderbird and some other IM software?
    • Should we detect already configured email accounts that are likely also usable for IM? (@gmail.com, @aol.com, @hotmail, ...)
  • Thunderbird users without IM account/experience?
    • Should we offer to create an account during the first startup?
  • People using competing software that already integrates email and IM (Gmail website, Outlook+Office Communicator, ...)?

• What's the minimum viable product?
  • Seeing if the sender of an email is online and being able to click to start an IM conversation in the system default chat client?
    • If centralizing all the user's communication in a single application is a goal, then it's not enough.
  • Providing a reliable offline archive of all messages exchanged on some networks? (for example a read-only copy of all twitter messages)
    • Need user research to know which networks matter.
  • The short term goals we pick need to be compatible with the long term vision.
    • Is it OK to rely on other IM clients of the system if we intend to develop a mobile version later?
    • If we want to help users to "own" their data by regrouping all the communication data in a single place where it's easy to manage, is it acceptable to delegate communication tasks to external applications? (shouldn't we have control over encryption? are there potential privacy issues?)

|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. |Feature users and use cases=Targeted users are people who use Thunderbird for their emails and may IM the same set of contacts.

Additional value should come from bringing IM features closer to Thunderbird, for example:

• Seeing that the sender of an email is available to chat may lead the user to decide an IM conversation is better to get some clarification about some points of the email he was reading.
  • Then the IM conversation could be somehow "attached" to the email. The conversation could annotate the email, so that searching the archives for the email also brings up the IM comments.
• When a user is about to start an IM conversation with a contact, showing the list of exchanged emails with this person could avoid wasting time for both people (maybe the desired information is right there in the bulk of unread emails? Maybe the latest email explains why the person wouldn't be able to give a useful answer anyway? ...)
• When trying to get back to some piece of information obtained in the past from someone, searching in both email and IM archives removes for the user the burden of remembering which communication medium was used.
• Forwarding (parts of) an IM conversation should be easier if the IM conversation is reachable directly from Thunderbird.
• If emails are shown in a conversation view, integrating in that view the IM conversations that happened on the same subject could give a better overview of the exchanges.
• (assuming calendar integration) While setting up an event, seeing that some of the invitees are online and starting an IM conversation with them could help discuss and find a possible date/time faster.
• Collaborative editing: asking someone who's available to proof read an email draft, and discussing the proposed changes in an IM conversation.

|Feature 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. (?)

|Feature requirements=* Manage contacts for email and IM in a single place.

• Search both Email and IM archives at once.

|Feature 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.

|Feature functional spec=(at this point the content of this section is a draft, still open to discussion)

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 are open (or at least documented)
    • they are widely used in the Mozilla comunity
    • the user interactions are significantly different from those with XMPP, which will force us to iron out some UI integration issues that may be unoticed with XMPP.
• A plugin system should let users add support for more protocols (even closed protocols) with add-ons.

IM accounts management

• 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? Existance 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?)
• The 'Add Other Account...' wizard should offer a way to set up an IM account manually.
• The 'Account Settings...' dialog should let users configure settings of their IM accounts.

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.

General IM UI

• IM features shouldn't get in the way of users interacting with their emails.
  • 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 features should be tightly integrated into the Thunderbird UI, so that they don't feel like something added after the fact.

Archives

• IM conversations should be stored, 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.

|Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority	Unprioritized
Rank	999
Theme / Goal	`
Roadmap	Thunderbird
Secondary roadmap	`
Feature list	Thunderbird
Project	`
Engineering team	Thunderbird

{{#set:Feature priority=Unprioritized

|Feature rank=999 |Feature theme=` |Feature roadmap=Thunderbird |Feature secondary roadmap=` |Feature list=Thunderbird |Feature project=` |Feature engineering team=Thunderbird }}

Team status notes

	status	notes
Products	`	`
Engineering	`	`
Security	`	`
Privacy	`	`
Localization	`	`
Accessibility	`	`
Quality assurance	`	`
User experience	`	`
Product marketing	`	`
Operations	`	`

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}