1082546 - [Messages] When we receive a message for a thread and a notification exists, we should display how much messages are unread in that thread

Status: RESOLVED WONTFIX

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

Description

[Julien Wajsberg [:julienw]]

STR:
* receive 2 messages from the same phone number

Expected:
* "2 unread messages" displayed in the notification

Actual:
* The text of the last message is displayed in the notification

NI Jenny for more information
NI Bevis because having a "getThread(id)" API would be very useful here.

Comment 1

[Julien Wajsberg [:julienw]]

(In reply to Julien Wajsberg [:julienw] from comment #0)

> NI Bevis because having a "getThread(id)" API would be very useful here.

Note that this is not mandatory, we can store this information in the notification itself, but it's not as good. For example, with this API, we could send the notification only once for several received message (at reboot for example).

Comment 2

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Julien Wajsberg [:julienw] from comment #1)
> (In reply to Julien Wajsberg [:julienw] from comment #0)
> 
> > NI Bevis because having a "getThread(id)" API would be very useful here.
This makes sense to me.
> 
> Note that this is not mandatory, we can store this information in the
> notification itself, but it's not as good. For example, with this API, we
> could send the notification only once for several received message (at
> reboot for example).

Bug 1083003 has been filed to address this.
I am working on some P1 item for v2.2 currently.
I'll try to add this when available. :-)

Comment 3

[Jenny Lee]

(In reply to Julien Wajsberg [:julienw] from comment #0)
> STR:
> * receive 2 messages from the same phone number
> 
> Expected:
> * "2 unread messages" displayed in the notification
> 
> Actual:
> * The text of the last message is displayed in the notification
> 
> NI Jenny for more information
> NI Bevis because having a "getThread(id)" API would be very useful here.

Hi Julien,
Are you referring to the in app banner? If so, your proposal definitely provides better UX. So if it's doable, we can move forward ;) thanks!

Comment 4

[Julien Wajsberg [:julienw]]

Hey Jenny,

no I'm referring to the System notification :)

This is one of the things that upsets me a lot: the fact that I only see the latest message for a thread, even if I received several of them. I have no way to know this if I don't open the app.

Hope this is clearer.

Comment 5

[Jenny Lee]

I was secretly hoping it's the in app banner :p

I absolutely agree with you on this one. Before we move forward, I want to know if you agree with the idea of aggregating message notifications as mentioned in Bug 989182 comment 24, I think we need to consider this altogether. Just a quick reminder that I won't be able to support this until late November :(

Comment 6

[Julien Wajsberg [:julienw]]

Jenny, yep, I agree with this :) (as I said in the next comment in the same bug :) )

This bug is only about aggregating the existing notifications though, and not sending new notifications for error case (because we need gecko support for this).

To move forward, I think we only need the text to put in the notification when we aggregate 2 "received message" notifications for one thread.

I can propose:
Title: same as currently: (SIMx) contact name/phone number
Message: You have n unread messages.

Another possibility: "sent you n messages"
But it feels weird because we only display the count for unread messages.

NI Jenny for a first proof reading :)

Comment 7

[Jenny Lee]

Attachment: Screen Shot 2014-10-28 at 5.56.39 PM.png

Alright, let's focus on this task for now ;)
To align with possible future aggregation notification, which would probably look like the attachment, I'm thinking for single sender multiple messages notification will be:

Sender name or number
%number new messages

This is pretty similar to your proposal, instead of using the word "unread", I used "new" cause it's more positive. Let me know what you think, thanks!

Comment 8

[Jenny Lee]

ps. please ignore the styling of attachment 8512537 [details] but focus on the wording.

Comment 9

[Julien Wajsberg [:julienw]]

Mmm I thought we would have 1 notification per thread instead of 1 notification for all. I misunderstood what you said in the other bug !

Having 1 notification for all received messages have these issues:
* we can't display it like this ('<contact names>... (+2)') because we simply send a title to the Notification API. Best we can do is "<contact names>..." :/
* more importantly: what is the action when clicking the notification? Currently we open the thread, which is convenient, but with such a notification we would open the thread list instead, I guess.

These 2 limitations make me think that it's better to have 1 notification per thread... what do you think?

Comment 10

[Jenny Lee]

The purpose of merging all the notifications is to avoid flooding notification tray, the downside is we probably won't be able to show message preview. I didn't realize we can't display ('<contact names>... (+2)') in notification though... this would be the real problem. Tapping the notification would simply go to message inbox as you said ;)

Given the limitation, let's just make the change to address the issue in this bug. String proposed:

Sender name or number
%number new messages 

Thanks!

Comment 11

[Julien Wajsberg [:julienw]]

NI Michael on the notification ellipsis issue, he may be aware of more long-term solution?

Comment 12

[Michael Henretty [:mikehenrty][:mhenretty]]

Yeah, there is no real way to do the ellipses as specified in the spec. It is a limitation of the notification API in b2g.

Also, my two cents, I really enjoy having a separate notification for each thread. Text messages are really important to me, and so I generally check them often enough that they don't overwhelm the utility tray. And even if I turn my phone off or leave the country for a few days, I don't mind having a list of reminders in the utility tray about who texted me.

Comment 14

[Julien Wajsberg [:julienw]]

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

Comment 15

[Julien Wajsberg [:julienw]]

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