Features/Thunderbird/Instant messaging in Thunderbird: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(37 intermediate revisions by 6 users not shown)
Line 1: Line 1:
{{FeatureStatus
{{FeatureStatus
|Feature name=Instant messaging in Thunderbird
|Feature name=Instant messaging in Thunderbird
|Feature stage=Draft
|Feature stage=Shipped
|Feature status=In progress
|Feature status=In progress
|Feature version=Thunderbird 15
|Feature health=OK
|Feature health=OK
|Feature 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.
}}
}}
{{FeatureTeam
{{FeatureTeam
|Feature product manager=Florian Quèze
|Feature product manager=Florian Quèze
|Feature security lead=Paul Theriault
}}
}}
{{FeaturePageBody
{{FeaturePageBody
|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:
|Feature open issues and risks=See [[Talk:Features/Thunderbird/Instant_messaging_in_Thunderbird|the discussion page]] for a summary of questions that were discussed while this page was a draft and answers that were gathered.
|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.
 
====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.


* 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.)
====Leveraging links between IM conversations and emails====
** Using the default IM client seems like a false good idea because:
* Keeping links between emails and the related IM conversations can simplify further processing of the exchanges:
*** 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.
** when rereading the whole discussion
*** 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.
** when forwarding it
*** 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.
* 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).
** 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).
* 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


* 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.
(See also the "How can this bring additional value for users?" question on [[Talk:Features/Thunderbird/Instant_messaging_in_Thunderbird|the discussion page]] for some related discussion and a few possible future use cases).
** Showing IMs above may be interrupting/distracting.
|Feature dependencies=* <del>Address book updates to support IM addresses for different networks (?)</del>
** IMs may go unnoticed if they aren't visible enough, and lose the benefit of "instantness" that IM has compared to email.
* <del>Composing in a tab, so that potential IM activity indicators placed in the main UI stay visible. (?)</del>
** (Gmail shows IMs above emails.)
|Feature requirements=* IM right from Thunderbird
** 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)
* 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.
|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=====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.


* What's the scope of "instant messaging"?
====IM networks/protocol support====
** In this context, IM may extend to social network communications, or even to telephony or anything providing a more "instant" communication than email.
* Thunderbird will support by default only a few IM protocols
** Should we include social networks (like twitter/facebook/...)?
** XMPP is a good first candidate:
*** 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.
*** it's an open standard
** Which networks of "instant" communication make sense here?
*** it gives access to some quite popular IM networks (Google Talk, Facebook Chat).
*** Probably depends on what the users we target need or already use.  
** IRC and Twitter are also interesting candidates (they can come later though):
*** Need some user research.
*** 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.
* A plugin system should let users add support for more protocols (even closed protocols) with add-ons.


* Who are the target users?
====IM accounts management====
** People already using both Thunderbird and some other IM software?
* The 'Account Settings...' dialog should let users configure settings of their IM accounts.
*** Should we detect already configured email accounts that are likely also usable for IM? (@gmail.com, @aol.com, @hotmail, ...)
* An 'Add Instant Messaging Account...' menu item lets the user open a wizard to set up an IM account.
** 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?
* no longer planned for the first version shipping with IM: <del>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?).</del>
** 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?
** <del>If an IM account is found, the default action would be to configure Thunderbird to use it.</del>
*** If centralizing all the user's communication in a single application is a goal, then it's not enough.
** <del>It should be possible to opt-out from this behavior (checkbox "also use this account for instant messaging", checked by default?)</del>
** 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.
====Address book integration====
** The short term goals we pick need to be compatible with the long term vision.
* Address book cards will support multiple IM contact info for each contact.
*** Is it OK to rely on other IM clients of the system if we intend to develop a mobile version later?
* Whenever possible, IM contacts will be associated with email contacts automatically.
*** 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?)
* Users will also be able to add associations between IM and email contacts by hand.
|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.
====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.
|Feature ux 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: <em>still being discussed</em>
* Adding IM contacts: (<em>still being discussed</em>) 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.
|Feature 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.


Additional value should come from bringing IM features closer to Thunderbird, for example:
Main tasks:
* 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.
* remove the dependency of the IM core of Instantbird on libpurple. (almost done, work tracked in Instantbird [https://bugzilla.instantbird.org/show_bug.cgi?id=759 bug 759])
** 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.
* integrate more protocol plugins implemented in JavaScript.
* 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? ...)
** Instantbird 1.0 and 1.1 shipped with only Twitter implemented in JavaScript.
* 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.
** An XMPP implementation in JS has been developed this summer by a Google Summer of Code student. (currently being reviewed in Instantbird [https://bugzilla.instantbird.org/show_bug.cgi?id=1171 bug 1171])
* Forwarding (parts of) an IM conversation should be easier if the IM conversation is reachable directly from Thunderbird.
** An IRC implementation in JS has been developed by an Instantbird developer. (needs a review, tracked in Instantbird [https://bugzilla.instantbird.org/show_bug.cgi?id=507 bug 507])
* 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.
* conversation logs should be written in an easily parsable format (best candidate seems JSON), and indexed in gloda.
* (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.
* integration into the current address book
* Collaborative editing: asking someone who's available to proof read an email draft, and discussing the proposed changes in an IM conversation.
* UI integration, the current plan, designed so that we can try a working prototype as soon as possible, is roughly:
|Feature dependencies=* Address book updates to support IM addresses for different networks (?)
** start by the changes needed so that IM accounts can be added/configured
* Composing in a tab, so that potential IM activity indicators placed in the main UI stay visible. (?)
** then add the UI where conversations can happen
|Feature requirements=* Manage contacts for email and IM in a single place.
** finally, iterate on other integration points and polish details until we are satisfied.
* Search both Email and IM archives at once.
|Feature implementation notes=Tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=714733
|Feature non-goals=* Turn Thunderbird into an IM client. The goal is not to attract people who don't intend to use Thunderbird for their emails.
}}
}}
{{FeatureInfo
{{FeatureInfo
|Feature priority=Unprioritized
|Feature priority=P1
|Feature rank=100
|Feature roadmap=Thunderbird
|Feature roadmap=Thunderbird
|Feature list=Thunderbird
|Feature list=Thunderbird
|Feature engineering team=Thunderbird
|Feature engineering team=Thunderbird
}}
}}
{{FeatureTeamStatus}}
{{FeatureTeamStatus
|Feature security status=sec-review-complete
|Feature security health=OK
|Feature security notes=[[Securtiy/Reviews/IMinThunderBird | Notes]]
}}

Latest revision as of 11:47, 25 September 2012

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

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.
  • 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 ` `


Retrieved from "https://dev.wikimo.nonprod.webservices.mozgcp.net/index.php?title=Features/Thunderbird/Instant_messaging_in_Thunderbird&oldid=473450"