Closed Bug 916516 Opened 11 years ago Closed 11 years ago

[leo][1.2][Email] Notifications UI does not match UX spec version 0.4 dated July 26, 2013

Categories

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: parul, Unassigned)

Details

Attachments

(4 files)

Test Environment:
Device: Leo
OS version: 1.2.0.0-prerelease
Firmware revision: D300f10a
Hardware revision: d300
Platform version: 26.0a1
Gecko: 53d5e43e23cc
Build Identifier: 20130914040202
Update channel: leo/1.2.0/nightly
Gaia: 3f51f302c3a0c57d8bad482ec7ee86b2819389fb1379079409
Git commit info: 2013-09-13 13:36:49

Steps to reproduce:
1. Go to Settings > Display and set Screen timeout to 1 minute.
2.  On the home screen, tap on the E-Mail icon to launch the email app. 
3. Setup a new email account or ensure that one is already configured with the following options:
   A. Check for new messages: Every 5 minutes
   B. Display notifications for new messages: ON 
4. Press the home button to send the email app in the background. 
5. Allow the phone screen to time out through inactivity.
6. On a computer, sign in to the configured email account and arrange to receive emails in it. (This can be done either by sending emails from another account or by subscribing to a high-volume mailing list.)  

Expected Results: 
After 5 minutes, the email app should sync with the mail server. The email app should generate a notification of new email received on the phone lock screen as well as the Utility Tray. The UI implementation should match the UX spec Version 0.4 (file name: DRAFT-email-1-2release-130726.pdf) hosted at
https://mozilla.app.box.com/s/bgrftq1jr38rwzb173zj  
Engineering work tracked in Bug 892522.

Actual Results: 
After the email app syncs with the mail server, it generates a notification of new email received on the phone lock screen as well as the Utility Tray but the UI implementation does not match the UX spec mentioned above.

Single Email Notification UI on Lock Screen and Utility Tray:
Expected: Sender name on first line, Subject on second line in bold, Absolute time of email (e.g. 1:36pm)
Actual: Subject on first line in bold, Sender name on second line, Relative time of email (e.g. "just now")

Multiple Email Notification UI on Lock Screen and Utility Tray:
Expected: Number of new emails on first line in bold, Sender name on second line in bold, Subject on third line, Absolute time of email (e.g. 1:36pm), emails listed in reverse chronological order (newest at the top, oldest at the bottom)
Actual: Number of new emails on first line in bold with capitalization of words (i.e. "New Emails"), hyphen as separator on the same line, email address of account synced on the same line, Relative time of email (e.g. "just now"), Sender names on second line separated by commas in chronological order (oldest first, newest last) with truncation  
(see screenshot attached)

Steps to reproduce (continued):
7. Setup another email account or ensure that a second one is already configured with the following options:
   A. Check for new messages: Every 5 minutes
   B. Display notifications for new messages: ON 
8. Press the home button to send the email app in the background. 
9. Allow the phone screen to time out through inactivity.
10. On a computer, sign in to the second email account and arrange to receive emails in it. 
11. Also arrange to receive emails in the first email account configured on the phone.

Expected Results: 
After the email app sync with both the mail servers, it should generate a notification of new email received for both the accounts on the phone lock screen as well as the Utility Tray. The UI implementation should match the UX spec mentioned above, the principal requirement being that the 2 different email accounts should be clearly distinguished.

Actual Results: 
After the email app syncs with the mail server, it generates a notification of new email received on the phone lock screen as well as the Utility Tray but the UI implementation does not match the UX spec mentioned above. The 2 different email accounts are not clearly distinguished; it is not possible to tell which email was received in which account.

Single Email Notification UI on Lock Screen and Utility Tray:
Expected: Sender name on first line, Subject on second line in bold, Absolute time of email (e.g. 1:36pm), email icon and email account on third line
Actual: Subject on first line in bold, Sender name on second line, Relative time of email (e.g. "just now")

Multiple Email Notification UI on Lock Screen and Utility Tray:
Expected: Email address on first line, Number of new emails on second line in bold, Sender name on third line in bold, Subject on fourth line, Absolute time of email (e.g. 1:36pm), emails listed in reverse chronological order (newest at the top, oldest at the bottom)
Actual: Number of new emails on first line in bold with capitalization of words (i.e. "New Emails"), hyphen as separator on the same line, email address of account synced on the same line, Relative time of email (e.g. "just now"), Sender names on second line separated by commas in chronological order (oldest first, newest last) with truncation  
(see screenshot attached)
Thank you for the very detailed bug!  The UX specs are unfortunately more like UX wishes in this case and were superseded by discussion with UX given the limitations of the notifications API and B2G/Gaia implementation of the presentation.

Right now we really only have 2 lines of text available to us with no formatting options supported (which also impacts our ability to indicate which data is sourced from the message and which is from the app) and very little horizontal screen real estate on our shipping devices.  (320 horizontal pixels is the baseline.)

Being able to tell which account the messages were received on in all cases would be handy and seems like a valid enhancement request.  But because the account name can be very long and subjects/sender can be very long, it's not clear how to integrate that given the existing notification API.  (When just listing the number of new messages, it's okay, because that's small.)  Given what's available to us right now, we might be able to use a different icon for each account, although I believe that's functionality that's going to be removed for anti-spoofing reasons.  (And Gaia may not be spec compliant in supporting that currently.)

If there are other specific deficiencies of the implementation where we're buggy or you think we could do something different but still meet the original goals of the UX specs, please file bugs on those with your proposed enhancement.  Bugs that involve making enhancements to the notifications infrastructure of Gaia should probably be deferred in favor of mailing the dev-gaia, dev-webapi, or relevant W3C/WHATWG lists to discuss enhancing the notifications API first.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: