View source for Talk:Features/Thunderbird/Instant messaging in Thunderbird

These points were actively discussed while [[Features/Thunderbird/Instant_messaging_in_Thunderbird|the feature page]] was a draft. Here's a summary of the questions and some answers that were gathered:

* 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 an external 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 IM client the user already has may be hard because:
*** There are lots of different clients out there. Integrating will all of them is impossible.
*** All clients may not have a good API (if they have one at all).
*** 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 that we don't really know.
** Integrating with the existing IM clients seems like it could help us ship something sooner... but if we end up having to ship our own stack later, integrating with external clients first is a waste of time/resources.
** We could pick a small set of clients for each platform and do the integration work only for them:
*** How would we select them? (Popularity? Open-source-ness?)
*** If we provide a good API and the integration is appealing, the teams working on other clients may get interested and do their part of the integration work.
** Having some built-in protocol implementations doesn't dispense us from having a plugin system for protocols which, by their closed nature, can't be implemented directly (obvious example: Skype).
** Using external clients would avoid showing contacts when Thunderbird needs to be restarted for some reason (add-on installs, ...).

* 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?)


* How can this bring additional value for users?
** 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.
** (assuming calendar integration) Changing the IM status automatically to 'Do not disturb' during meetings that are indicated by the calendar.
** Collaborative editing: asking someone who's available to proof read an email draft, and discussing the proposed changes in an IM conversation.