61
edits
Changes
no edit summary
}}
{{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 hereSee [[Talk: * 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, Features/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 Instant_messaging_in_Thunderbird|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 discussion page]] 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 summary 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" questions 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 were discussed while 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 page was 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 draft 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 answers 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 enoughwere gathered.** 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.
