61
edits
Changes
no edit summary
** 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"?
** Which protocols of "instant" communication make sense here probably depend on what the users we target need or already use. 'protocols' might be less relevant than 'network' from a user stand point. I suggest we use this word rather than the technical one.
** What network list should we consider ?
*** Need some user research.
* Who are the target users?
*** 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?
*** 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 intend to develop a mobile version later?
|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.
