796751 - [email][notifications] UX: what to do for e-mail notifications when we can't retract or modify notifications?

Status: RESOLVED DUPLICATE of bug 892522

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

Description

[GH to BZ]

[GitHub issue by asutherland on 2012-09-27T05:48:48Z, https://github.com/mozilla-b2g/gaia/issues/5275]
@caseyyee @vingtetun (for technical sanity checking for my API understanding, workarounds)

If I read http://dxr.allizom.org/mozilla-central/dom/interfaces/notification/nsIDOMDesktopNotification.idl correctly, we can only create notifications.  We can't update them or retract them, which is unfortunate, because the dream would be to start out with details on the 1 new message, but if there are multiple messages to then maybe provide some summary (messages from bob, susan, tom), then finally giving up and saying "you have 100 new messages.)"

This would seem to leave us with 3 main classes of options:
- too many?: send a notification for every new e-mail we receive, even though this could end up ridiculous.
- too few?: When we first see a new message for an account, say, "You have 1 or more new messages for this account".  Leave that until the user clears the notification, which resets our ability to trigger.
- bounded: Provide per-message details for up to N-1 messages (per account?).  At the Nth messages, send a generic "and there are other new messages; click to see them or clear your notifications so we can tell you about more new ones".

Comment 1

[GH to BZ]

[GitHub comment by asutherland on 2012-10-01T06:20:25Z]
What I landed currently will allow up to 5 notifications to be issued per account.  We stop issuing notifications for an account once this limit has been reached.  If I did it right, when the notifications go away the count goes back down and new notifications can be issued.

Comment 2

[ayman maat :maat]

[UX-P?] no movement on this bug for some time
request QA to test to see if it is still valid

Comment 3

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

periodic synchronization and notifications were moved out of v1 into v2.  In v2 the platform will probably improve notifications, but we should keep this bug around until that happens.  At that point we should create a revised bug to have our wireframes describe what our notifications should do in these broad cases.

Comment 5

[qgil]

After 24h using the ZTE Open I believe this is the weakness number 1 of this product.

I'd say any type of notifications is better than no email notifications at all.

(In reply to GH to BZ from comment #0)
> - too few?: When we first see a new message for an account, say, "You have 1
> or more new messages for this account".  Leave that until the user clears
> the notification, which resets our ability to trigger.

This sounds like the best option among the three listed above.

Other systems (e.g. Wikipedia) send you just one notification until they hear about you. Not perfect for a mobile device but users getting such device now will probably understand (better than if they get no notifications at all).

Comment 6

[James Burke [:jrburke]]

This work is scheduled for 1.2, tracked in bug 892522. Even though this bug was opened first, marking this bug as a duplicate of 892522 since the other bug has product and UX guidance, and will be tied to bug numbers that are tied to system Notification work around revoking and modifying existing notifications.