989182 - Consider limiting notifications from the SMS App

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::SMS, defect)

Description

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

The test in bug 981871 sends SMSs to a number that does not support them.  Apparently the SMS app raises a notification for each message that we fail to send.  Perhaps we should consider raising a single notification for all messages sent to the same number.

Comment 1

[Julien Wajsberg [:julienw]]

You mean the delivery/read notifications?

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

No, apparently there is some sort of "failed to send the message" notification.

Comment 3

[Julien Wajsberg [:julienw]]

Ok, I'm quite sure this is actually a delivery notification.

We don't do notification coercion yet, and I agree this is a good idea, even for other notifications we have.

Comment 4

[Nicholas Nethercote [inactive]]

This doesn't feel blocker-worth to me. Sending hundreds of SMSs to a number that doesn't support them is not something a human user would do.

Comment 5

[Nathan Froyd [:froydnj]]

(In reply to Nicholas Nethercote [:njn] from comment #4)
> This doesn't feel blocker-worth to me. Sending hundreds of SMSs to a number
> that doesn't support them is not something a human user would do.

I feel like you have too-high expectations for what human users do.

Comment 6

[Preeti Raghunath(:Preeti)]

Product,

Do we want to flag the max number of open notifications?

Comment 7

[Julien Wajsberg [:julienw]]

What we really want to do, in my opinion, is to merge notifications. This can be done either in the app, or the system might do it automatically.

Comment 8

[Gabriele Svelto [:gsvelto]]

(In reply to Julien Wajsberg [:julienw] (away until March 24) from comment #7)
> What we really want to do, in my opinion, is to merge notifications. This
> can be done either in the app, or the system might do it automatically.

Are we using the new Notification API already in the SMS app? If we are then merging notifications should be a piece of cake. From a UX perspective how should that look like? Displaying only the last message for every contact? Or if there's more than one message pending show the number of unread messages for that particular contact?

Comment 9

[Jason Smith [:jsmith]]

This is a great idea, but I don't think this is a blocker. This isn't realistic for a user to trigger & has been present since 1.01.

Comment 10

[Julien Wajsberg [:julienw]]

(In reply to Gabriele Svelto [:gsvelto] from comment #8)
> (In reply to Julien Wajsberg [:julienw] (away until March 24) from comment
> #7)
> > What we really want to do, in my opinion, is to merge notifications. This
> > can be done either in the app, or the system might do it automatically.
> 
> Are we using the new Notification API already in the SMS app? If we are then
> merging notifications should be a piece of cake. From a UX perspective how
> should that look like? Displaying only the last message for every contact?
> Or if there's more than one message pending show the number of unread
> messages for that particular contact?

I would do the latter, but UX needs to decide.

And also, I really think having a generic way in the system app would be useful too: as soon as an app has several notifications, it could merge them in one and have an action button to let the user display all of them for one app.

But we can do both: if an app has only one notification displayed, then the notification would be displayed in all its glory.

Comment 12

[Julien Wajsberg [:julienw]]

bug 806595 is essentially the same except it focussed only on "SMS received" notifications. See especially bug 806595 comment 6 explaining how we could have a feature in the system app with different behavior for the notification tray and for the lockscreen.

Stephany, I know we already discussed about this a long time ago (bug 806595) but this never moved forward. Is it about time?

Here are my questions:
* should the system app display differently the notifications when one app sends more than one? Different behavior in lockscreen and notification tray?
* should the apps themselves limit the notifications by replacing them? Still one app can have different notifications "type" (for example in SMS: sms received, delivery reports, read reports) so we could still have several notifications for one app even if it tries to limit them.

Comment 13

[Stephany Wilkes]

This isn't a UX call, but is enough of a change that it would likely warrant a feature being added to the Comms backlog (which I think makes sense). Flagging Wilfred for 2.1 planning and Rob on the Sys FE side.

Comment 14

[Julien Wajsberg [:julienw]]

On the SMS side, Bug 994823 is related and will already do some work when we receive several SMS from one person (which is a simple use case). But we need the big picture on the OS level.

Comment 15

[Wilfred Mathanaraj [:WDM]]

Omega can provide a guideline as to how best we can do this and based on this we can see if this can be put into one of the next releases.

Comment 16

[Julien Wajsberg [:julienw]]

Again, I'd still someone to comment on the OS level here. Why is it that difficult to take a OS-wide decision?

Comment 17

[Rob MacDonald [:robmac]]

(In reply to Wilfred Mathanaraj [:WDM] from comment #15)
> Omega can provide a guideline as to how best we can do this and based on
> this we can see if this can be put into one of the next releases.

Although I'm the UX owner for notifications, I'm currently leaving grouping up to individual applications depending on their needs. Email, for example, has chosen to group new messages but the UX decision in this case would be up to the UX owner of messaging. Omega, you're already flagged, but get in touch with me if you want to discuss this further. 

As a general feature, we should also add notification management as a user-facing feature to our backlog. This is an app-level control at the moment but should be consolidated.

NI me if you have further questions or concerns.

Comment 18

[Omega Feng [:Omega] [:馮於懋]]

We can have a OS-wise guideline, but I agree each app can still has its own behaviors.
For Messages, let's group notifications by the same phone number, regardless of notification types. Show the latest notification type for one number, for example:
1) For phone number 0912345678, I gets its delivery report, so the notification shows that delivery report,
2) and then I gets its read report, so the notification shows that read report, replacing the delivery report;
3) and then it sends me a message, so the notification shows that unread message, replacing the read report.

Comment 19

[Julien Wajsberg [:julienw]]

Omega, I don't think this is wise to do this.

If I'm not looking at notifications, I'll see only the last one, with no indication that I had other notifications before. Same when we get several messages from the same number, I think it's important to show this differently than when we just got one message.

IMO it's better to group by notification type than by number. We would say "we received 3 messages from XXX and XXX" (one of them sent 2 messages) or "we received 3 read reports from XXX, XXX and others".

Comment 20

[Julien Wajsberg [:julienw]]

And clearly, from my point of view, we need a way to let the user see all sent notifications if he wants to. But this could happen only in the System app.

Comment 21

[Omega Feng [:Omega] [:馮於懋]]

I assume the most important thing is I get a message from a phone number.
So, when I get a message from a phone number, I'll go to the message thread to see the full message, and I'll know the whole message log (delivery report/read report) in that thread.

If I see a delivery report or read report in notification panel, I will know that the number didn't send me messages which I haven't read, because he cannot send me a message before receiving/reading my message.

I guess sometimes the above logic may be wrong due to some delay issue, but I prefer that if it doesn't happen very often, because that keep the notification panel simpler.

Comment 22

[Julien Wajsberg [:julienw]]

(In reply to Omega Feng [:Omega] from comment #21)
> I assume the most important thing is I get a message from a phone number.
> So, when I get a message from a phone number, I'll go to the message thread
> to see the full message, and I'll know the whole message log (delivery
> report/read report) in that thread.

But that's not what you (as a user) will look after if you read the thread after a "message received" notification.

> 
> If I see a delivery report or read report in notification panel, I will know
> that the number didn't send me messages which I haven't read, because he
> cannot send me a message before receiving/reading my message.

Of course he can :) 
<my-life>my girldfriend very often send me a message without reading mine before</my-life>

> 
> I guess sometimes the above logic may be wrong due to some delay issue, but
> I prefer that if it doesn't happen very often, because that keep the
> notification panel simpler.

So, if I follow your first affirmation "the most important thing is I get a message from a phone number", what happens if we have a "sms received" notification, but then you get the "read report" notification? Should we replace the existing "sms received" notification, or should we display the "read report" notification?
I agree this will happen rarely but this _will_ happen.

Comment 23

[Omega Feng [:Omega] [:馮於懋]]

ni? new UX owner Jenny.

Comment 24

[Jenny Lee]

Hello Julien, 
IMO, for message, there should be only 2 types of notification: 1) message received and 2) message failed to send (that is when Message is in background, if user stays on the same page where he sent the message, there will be no notification. Instead, a fail to send message dialogue box will appear). We are already showing "message delivered" and "message read" icon in thread view if user turns on the feature in settings, I don't see the need to send extra notifications. As this is how it's done in most texting apps like whatsapp or line. 

That being said, I don't find it necessary to merge the 2 types of notification mentioned above, even if they are related to the same phone number because they are essentially different. However, it is necessary to merge all "message received" notifications to one notification, and all "message failed to send" notifications to another. So at the same time, there will always be no more than 2 notifications coming from Message. Let me know what you think, thanks!

Comment 25

[Julien Wajsberg [:julienw]]

About read/delivery notifications, there has been requests to have notifications for this (see bug 1019341).

But overall I agree with you, I don't think we need notifications for success, and we definitely need notifications for failures.

Comment 26

[Jenny Lee]

(In reply to Julien Wajsberg [:julienw] from comment #25)
> About read/delivery notifications, there has been requests to have
> notifications for this (see bug 1019341).
> 
> But overall I agree with you, I don't think we need notifications for
> success, and we definitely need notifications for failures.

Hello Julien, I had a brief discussion with Wilfred about showing notifications for delivery/read report, we both agree that it's not a wanted feature as I explained in comment 24. I'll create a spec regarding merging same message notification type to address the issue described in bug. Tks!

Comment 27

[Julien Wajsberg [:julienw]]

Filed bug 1082546 for merging received message notifications, which is the case that bugs me the most.

Comment 28

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(

Comment 29

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(