811704 - [EMail] No audible notification is present.

Status: RESOLVED WORKSFORME

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

Description

[Patryk Adamczyk [:patryk] UX]

When an email is received the user should have an option to hear a notification. Can you please copy the code from SMS (Messages).

If the user goes to settings > sound
There should be an option to specify E-Mail Notifications, much like messages.

When selecting a tone for the E-Mail, there should be also be an option for:
a. no sound
b. vibrate only

Comment 1

[Etienne Segonzac (:etienne)]

Not that mozNotification are going to beep/vibrate to the app does not need to.
(patch for this in review)

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

We disabled periodic mail-checking and thereby disabled notifications in bug 804911.  Which means that currently, the only way a new message can be received is by direct user interaction.  When you enter a folder, we sync, and you should see the new messages.  When you hit the refresh button, we sync, and presumably you know that this means more messages have shown up if they are going to show up.

Which is to say, I don't think there's anything to do for this bug until we re-enable notifications.

Comment 3

[Patryk Adamczyk [:patryk] UX]

When the user manually checks for email and email appears, a notification sound should still play, to let the user know: "new email is here".

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Patryk Adamczyk [:patryk] UX from comment #3)
> When the user manually checks for email and email appears, a notification
> sound should still play, to let the user know: "new email is here".

We really need the notification stuff written up in the wireframes, even for just a v1 treatment.  (Things keep getting discussed on the bugs but then disappearing into the ether.)  Whoever does this, please be sure to address whether all messages that show up in the folder are new, or only those matching some standard of recency per the timestamp.  Newness is a tricky issue that we don't need to completely deal with, but there is arguably a difference between:
- a brand new message newer than any other messages in the folder
- a quasi-new message that is older than some of the messages in the folder but not super old in relative terms.  This can happen because of a folder move that maintains the INTERNALDATE (on IMAP), or just server semantic issues that are not defined by standard and beyond our ken (ActiveSync).
- a message that's a week old that got moved into the folder and is way back in the mesage list

Once the wireframes are updated and sufficiently clear, we can try and implement something assuming project management approves the effort, etc.

Comment 5

[Patryk Adamczyk [:patryk] UX]

Casey can you please comment on the above ^

Comment 6

[Patryk Adamczyk [:patryk] UX]

Casey can you please comment on the above ^

Comment 7

[Casey Yee]

As per Patryks comment:
"When the user manually checks for email and email appears, a notification sound should still play, to let the user know: "new email is here"."

New email should be defined as:
Brand new message (just received in the last sync operation) that is unread and is newer than any other messages in the folder.

When new email arrives a notification sound should be played.

Comment 9

[Patryk Adamczyk [:patryk] UX]

Sam can you enable this for v.1.1?

Comment 10

[Dietrich Ayala (:dietrich)]

Product team, please inform requirement of this for 1.1 release.

Comment 11

[Dietrich Ayala (:dietrich)]

Not blocking until all the product teams can get an agreement on this being required for 1.1.

Comment 12

[Peter Dolanjski [:pdol]]

(In reply to Dietrich Ayala (:dietrich) from comment #11)
> Not blocking until all the product teams can get an agreement on this being
> required for 1.1.

It is not a blocking requirement, but agree that it would be valuable.  Dietrich, would the use of the tracking flag apply in this case, or is that flag limited to defects?

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

Mass edit to set tracking-b2g18+ for these UX bugs that were called out for v1.1

Comment 14

[Andrew Overholt [:overholt]]

shira? -> tef?

Comment 15

[Daniel Coloma:dcoloma]

Not at blocker (at least for 1.0.1)

Comment 16

[Eric Pang [:epang] UX]

Sam, what's the status on this bug? Have you had a chance to look into this bug?

Comment 17

[Sam Joch [:samjoch]]

What's the sound for that bug ?

Comment 18

[Eric Pang [:epang] UX]

(In reply to Sam Joch [:samjoch] from comment #17)
> What's the sound for that bug ?

In the description of the bug Patryk wrote,

'Can you please copy the code from SMS (Messages)'.  

So we should use the same code and sound that we use in SMS for email.

Thanks!

Comment 19

[Eric Pang [:epang] UX]

(In reply to Eric Pang [:epang] from comment #18)
> (In reply to Sam Joch [:samjoch] from comment #17)
> > What's the sound for that bug ?
> 
> In the description of the bug Patryk wrote,
> 
> 'Can you please copy the code from SMS (Messages)'.  
> 
> So we should use the same code and sound that we use in SMS for email.
> 
> Thanks!


Hi Sam, have you had a chance to look into this bug?

Comment 20

[Eric Pang [:epang] UX]

(In reply to Eric Pang [:epang] from comment #19)
> (In reply to Eric Pang [:epang] from comment #18)
> > (In reply to Sam Joch [:samjoch] from comment #17)
> > > What's the sound for that bug ?
> > 
> > In the description of the bug Patryk wrote,
> > 
> > 'Can you please copy the code from SMS (Messages)'.  
> > 
> > So we should use the same code and sound that we use in SMS for email.
> > 
> > Thanks!
> 
> 
> Hi Sam, have you had a chance to look into this bug?

Hi Sam, I still haven't heard back from you about this bug.  Any news?

Comment 21

[Sam Joch [:samjoch]]

Andrew: Can you give some help on getting a way to add a notification when new emails are added into the list. I tried many things but i can't get to a satisfied patch ...

Comment 22

[Andrew Sutherland [:asuth] (he/him)]

Bug 826071 will implement the infrastructure for this.  If you're interested in the mechanics, check out the pull request on their, particularly in the comments on now-obselete hunks.  But otherwise this just needs to wait on that, especially since that's QE2 and this is not.

Comment 23

[Leo]

Hi Sam,

Please update the current status of this issue for our information.

Thanks.

Comment 24

[Sam Joch [:samjoch]]

Attachment: PR Github

Here is a patch.

Comment 25

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 771592 [details]
PR Github

I think this patch is currently moot.  This isn't requested on v1.1 and can't land there anyways because we are hard string frozen for v1.1 since June 30th.  (https://groups.google.com/d/msg/mozilla.dev.gaia/SrFrWrBNl20/scS-Qa1LXl8J)

Since we will be re-enabling periodic sync for v1.2 and that impacts sound notifications much more extensively and it's under discussion as to whether we move the notification settings for e-mail into e-mail itself, I think we should wait for UX wireframes for that and mark this bug as dependent on that bug and mark this bug fixed when that lands.

Comment 26

[Eric Pang [:epang] UX]

(In reply to Andrew Sutherland (:asuth) from comment #25)
> Comment on attachment 771592 [details]
> PR Github
> 
> I think this patch is currently moot.  This isn't requested on v1.1 and
> can't land there anyways because we are hard string frozen for v1.1 since
> June 30th. 
> (https://groups.google.com/d/msg/mozilla.dev.gaia/SrFrWrBNl20/scS-Qa1LXl8J)
> 
> Since we will be re-enabling periodic sync for v1.2 and that impacts sound
> notifications much more extensively and it's under discussion as to whether
> we move the notification settings for e-mail into e-mail itself, I think we
> should wait for UX wireframes for that and mark this bug as dependent on
> that bug and mark this bug fixed when that lands.

Hi Andrew, it's been a while since there's been any updates on this bug.  Is it still valid?

Comment 27

[Andrew Sutherland [:asuth] (he/him)]

James, we get our notification sounds from the notifications implementation, right?

Comment 28

[James Burke [:jrburke]]

asuth: correct, we do not get to specify any options on sound/vibrate/screen wake on the Notification from within the email app. The Notification code right now has a special hardcoded bypass for email for 1.2 to not turn on the screen if a notification comes in, but sound/vibrate still occurs.

This bug seems obsolete given the Email periodic sync/notifications that was done for 1.2, and if there are changes from the 1.2 behavior, new bugs can be filed. In particular, as part of that sync work, UX did not specify generating a sound if you have the email app open and looking at it. Just for the cases where the app was not visible, or if a background email account got a new message.

More granular notification behaviors need to be allowed per app. However, that is likely a section in the system settings, not something to implement directly in the email app. There is also bug 912645 to track allowing an app to set notification modes on a per Notification basis.

Comment 29

[Andrew Sutherland [:asuth] (he/him)]

Thanks, James.  Marking RESOLVED WORKSFORME on the basis that we can make sounds if the user wants them and everything else is an enhancement to that.  And most of the enhancement burden is on the system app, so there's nothing really actionable in the e-mail app until the system app lands the enhancements.