Gaia/Email: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(→‎Sprint Demos: Set up.)
 
(73 intermediate revisions by 8 users not shown)
Line 1: Line 1:
The Email app offers access to a user's favorite email services while maintaining a client-like experience.  This app will support common protocols like IMAP, POP3 and Microsoft Exchange.
== Design Specs ==


== Status ==
==== Interaction ====
* Feature Name: Gaia Email App
For the latest UX specifications, please visit:  
* Stage: Development
https://mozilla.box.com/applications
* Release Target: M3 Alpha


== Use Cases ==
[[Gaia/Email/UX/Decisions]] - Notable UX Decisions and rationales
*Tom sees email just as critical as his ability to make/receive phone calls and text messages
*Tom is a Hotmail user (~40% share in Brazil) and often checks his email on his desktop computer, but wants to stay connect to his family/friends so an email client is very important to him
*Tom has the ability to check if he received new messages
*Tom wants to be able to compose a new email directly from the Email app or from other Core Apps like the Contacts app
*Tom wants to be able to reply/replay all to messages as well as forward messages to his friends
*Tom uses IMAP with his Hotmail service, and the setup was extremely easy because all he had to do was enter his Hotmail email address and password and the Email app did all the setup for him
*Tom has the ability to mark messages as read/unread
*With IMAP, Tom has access to all his folders and messages moved and deleted between folders are automatically synced regardless of what client he accesses his inbox from
*Because Tom loves staying connected, he also has a 2nd email address that he has setup through his work - Tom's work supports Exchange and because the Email app also supports this protocol, by entering just his work email address and password, he is able to easily setup his account
*Tom's Email app support multiple accounts and offers his a unified inbox view of all messages from all accounts


== App Requirements ==
==== Visual ====
;Gaia v1
* [https://wiki.mozilla.org/Gaia/Design/BuildingBlocks new building blocks page]
*The Email app here offers key functionality that users would expect from existing email apps in the smartphone market today
* [http://mozilla-b2g.github.com/Gaia-UI-Building-Blocks/ old building blocks page, fairly broken]
*In the setup flow, the user has the ability to select from the world 3 largest email providers:
* Things you can look at but are not canonical; these are inputs to the building blocks / UX process:
**Hotmail
** [http://buildingfirefoxos.com/index.html some building block proposals you can look at]
**Yahoo! Mail
** [http://buildingfirefoxos.com/transitions.html#deeper visual demonstration of some proposed transitions]
**Gmail (Google Mail)
*The user is offered the ability to just enter their email address and password and the Email app should automatically configure their settings
**The Email app should default to IMAP if the service supports it and POP3 as a back-up
**For Exchange users, the Email app should automatically detect the incoming/outgoing server settings
*The user has the ability to check their messages in their inbox and folders
**We offer 4 intervals for pulling messages - 15 mins, 30 mins, 1 hr, 4 hrs
*When composing messages, the user has the ability to compose directly from:
**The Email app by auto-filtering names from the Contacts list or by manually entering in a name
**Another Core App such as the Contacts app when selecting an email address (this is defined in the Contacts app requirements)
*In the compose view, the user has the ability to compose to the :
**'To:' field
**'Cc:' field
**'Bcc:' field
*The user has the ability to reply/reply all to messages
*The user has the ability to forward messages
*The user has the ability to delete messages
*The user has the ability to mark messages read/unread
*The user has the ability to select multiple messages at one and perform the following actions:
**Move messages to a specific folder
**Delete messages
**Mark messages read/unread
*Email messages should appear in HTML and rich text if messages are sent in that format
**Plain text messages should default to a core font that is available in Gaia
*The user has the ability to pinch-to-zoom in on messages to improve readability


;Gaia v2
== Development ==
*The user has the option to push email messages to their email account
*The user has the ability to select multiple messages and "forward as an attachment"
*Selecting text, copy, paste support for email messages


== UX Design Specs ==  
The e-mail app consists of a back-end which is developed in https://github.com/mozilla-b2g/gaia-email-libs-and-more and a front-end which is developed as part of Gaia at https://github.com/mozilla-b2g/gaia/tree/master/apps/email.  The intent of separating the library from the UI is to make the back-end reusable.  The primary motivation is to allow a keyboard-friendly desktop UI to be developed against the library without trying to have a single UI trying to meet two radically different use cases.
*IxD v1: in progress
 
*VisDe v1: in progress
To re-cap, check out these projects / repositories:
* https://github.com/mozilla-b2g/gaia
* https://github.com/mozilla-b2g/gaia-email-libs-and-more
 
== Features ==
 
See [[Gaia/Email/Features]] for a partial list of things we currently support or don't support.
 
== Implementation ==
 
The following pages are an attempt to describe how the e-mail implementation works without requiring you to read the block comments in the source code in order to understand.  The goal is to provide context of the e-mail problem domain and our approach to dealing with it.  We are not going to go into low-level details because those can change frequently, but we will try to strike a balance by linking to the source code and its block comments.
 
* [[Gaia/Email/Implementation/Limits]]: Maximum sizes of things, stuff like that.
* [[Gaia/Email/Implementation/MailSynchronization]]: General sync strategy, how we sync IMAP, and how we sync ActiveSync.  Sadly, these are very different things because they are very different protocols.
* [[Gaia/Email/Implementation/MessageDisplayAndAttachments]]: Plaintext mail, HTML mail, quoting, attachments!
 
* [[Gaia/Email/Implementation/FakeServers]]: Fake IMAP and ActiveSync servers for testing purposes.
 
== Standardization Efforts ==
 
* [[Gaia/Email/Standards/PushNotifications]]: We want to try and get IMAP servers to support our [[WebAPI/SimplePush]] API, which just means being able to PUT/POST a small amount of data to a URL.
 
== QA / Filing Bugs ==
 
Bugs should be filed in bugzilla.mozilla.org under the "Boot2Gecko" product and "E-Mail" component.  When filing a bug, be sure to provide the details requested in [[Gaia/Email/RequiredBugInfo]].  It's preferred if you do a search within the component first to look for any bugs that might already be filed on the problem.  Unfortunately, there are still a lot of known bugs :(
 
Resources on how to provide information for bugs:
* [[Gaia/Email/RequiredBugInfo]]: What we need to be able to properly investigate a bug.
* [[Gaia/Email/ProvidingEmailsForDebugging]]: How to provide problematic e-mails so developers can directly reproduce problems.  You can either attach the e-mails as attachments to the bug or e-mail them directly to the developers working on the bug if you are somewhat concerned about the world seeing any of the information in the e-mail (but not concerned enough that you have a problem providing it to a developer.)
* [[Gaia/Email/DebuggingTricks]]: Trying to help reproduce a problem?  Here are some tricks you can use to make your life easier.
 
== Testing ==
 
* Front-End Tests
** live in the [https://github.com/mozilla-b2g/gaia gaia repo]
** Tests by default run against
* Back-End Tests
** live in the [https://github.com/mozilla-b2g/gaia-email-libs-and-more gaia-email-libs-and-more repo] (aka GELAM).  For info on the tests in general, see: [[Gaia/Email/LoggestTestFramework]]
** run against JS implemented fake-servers by default, but can be run against real servers as well.
** contain a mixture of test types:
*** unit tests. examples: test_intl_unit.js (simple), test_folder_storage.js (complex)
*** higher level tests. ex: test_imap_general.js
*** end-to-end-ish tests. ex: test_compose.js (creates a message with an attachment, sends mail to itself, checks the messages and the attachment, sends a reply, etc.)
 
== Dependencies ==
 
(or rather, dependencies with wiki pages that tell you stuff)
 
https://wiki.mozilla.org/Gaia/Email/ActiveSync
 
== Sprint Demos ==
 
Coming soon.
 
== Historical ==
 
* [[Gaia/Email/HistoricalReqs]]: Historial requirements and use cases that are misleading to keep on this page.
 
== Security Review ==
The security review of this app can be found [https://wiki.mozilla.org/Security/Reviews/Gaia/email here].

Latest revision as of 19:39, 12 November 2014

Design Specs

Interaction

For the latest UX specifications, please visit: https://mozilla.box.com/applications

Gaia/Email/UX/Decisions - Notable UX Decisions and rationales

Visual

Development

The e-mail app consists of a back-end which is developed in https://github.com/mozilla-b2g/gaia-email-libs-and-more and a front-end which is developed as part of Gaia at https://github.com/mozilla-b2g/gaia/tree/master/apps/email. The intent of separating the library from the UI is to make the back-end reusable. The primary motivation is to allow a keyboard-friendly desktop UI to be developed against the library without trying to have a single UI trying to meet two radically different use cases.

To re-cap, check out these projects / repositories:

Features

See Gaia/Email/Features for a partial list of things we currently support or don't support.

Implementation

The following pages are an attempt to describe how the e-mail implementation works without requiring you to read the block comments in the source code in order to understand. The goal is to provide context of the e-mail problem domain and our approach to dealing with it. We are not going to go into low-level details because those can change frequently, but we will try to strike a balance by linking to the source code and its block comments.

Standardization Efforts

QA / Filing Bugs

Bugs should be filed in bugzilla.mozilla.org under the "Boot2Gecko" product and "E-Mail" component. When filing a bug, be sure to provide the details requested in Gaia/Email/RequiredBugInfo. It's preferred if you do a search within the component first to look for any bugs that might already be filed on the problem. Unfortunately, there are still a lot of known bugs :(

Resources on how to provide information for bugs:

  • Gaia/Email/RequiredBugInfo: What we need to be able to properly investigate a bug.
  • Gaia/Email/ProvidingEmailsForDebugging: How to provide problematic e-mails so developers can directly reproduce problems. You can either attach the e-mails as attachments to the bug or e-mail them directly to the developers working on the bug if you are somewhat concerned about the world seeing any of the information in the e-mail (but not concerned enough that you have a problem providing it to a developer.)
  • Gaia/Email/DebuggingTricks: Trying to help reproduce a problem? Here are some tricks you can use to make your life easier.

Testing

  • Front-End Tests
    • live in the gaia repo
    • Tests by default run against
  • Back-End Tests
    • live in the gaia-email-libs-and-more repo (aka GELAM). For info on the tests in general, see: Gaia/Email/LoggestTestFramework
    • run against JS implemented fake-servers by default, but can be run against real servers as well.
    • contain a mixture of test types:
      • unit tests. examples: test_intl_unit.js (simple), test_folder_storage.js (complex)
      • higher level tests. ex: test_imap_general.js
      • end-to-end-ish tests. ex: test_compose.js (creates a message with an attachment, sends mail to itself, checks the messages and the attachment, sends a reply, etc.)

Dependencies

(or rather, dependencies with wiki pages that tell you stuff)

https://wiki.mozilla.org/Gaia/Email/ActiveSync

Sprint Demos

Coming soon.

Historical

Security Review

The security review of this app can be found here.