926852 - [Messages] Read receipts feature Gaia implementation

Status: RESOLVED FIXED

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

Description

[Steve Chung [:steveck]]

To match the criteria in User Story(bug 919974), the necessary implementation in gaia will be:

- Having a new option for read report in settings app/mesage settings panel.
- Handling messageRead event callback and update the thread ui page.
- Handling messageRead attribute in message object and display the message read icon.

Comment 1

[Joe Cheng [:jcheng] (please needinfo)]

blocking a committed 1.3 user story. 1.3+

Comment 2

[Steve Chung [:steveck]]

Attachment: Link to github

Hi Julien, this patch enable the read report feature which is postponed from v1.3 and gecko side is already ready in master(gecko has one bug about the read report I found today, but it won't break the functionality and I will set it as blocker later). New thread ui view layout for delivered/read status is still unclear for me, so I keep the original tickle for both status and I'll update with thread ui view refresh. If you want to test with other message app, please make sure the target app support read report feature.

Comment 3

[Julien Wajsberg [:julienw]]

Comment on attachment 8371354 [details] [review]
Link to github

Sorry for being late, 1.3 sucked up all my time :(

Mostly nits, except the "live update the information report" part, that's why I'm not giving r+ yet.

Also, I couldn't check it works locally. I correctly get the "readsuccess" event but I miss the various properties.

Also, you'll need a review from a settings peer.

But this is otherwise a quite solid patch!

Comment 4

[Steve Chung [:steveck]]

Hi Julien,
May I know what kind of properties missed in you local build? Only read receipt related (readStatus/readTimestamp) or even delivery properties are also missed in deliveryInfo?

Hi Gene/Bevis,
Julien faced some problem in read receipt. In comment 3, he said he can get readsuccess event but there seems missing some properties related to read receipt. Is that possible?

Comment 5

[Julien Wajsberg [:julienw]]

The delivery properties were fine.

To find this, I simply debugged on the phone and put a breakpoint in "createReportDiv" to inspect the "reports" variable.

Comment 6

[Julien Wajsberg [:julienw]]

Not I'm not sure I had the readsuccess event, I thought I had it because I saw the green "tick" but maybe it was the delivery report instead. I'll chcek again today.

Anyway, do I need a special gecko patch to enable this, or is it supposed to be already in central?

Comment 7

[Steve Chung [:steveck]]

Comment on attachment 8371354 [details] [review]
Link to github

Hmm...the only thing need to do here is open the read receipt option in settings page and it should work on current master without any other trick. Please make sure both device flash to master with this patch, or make sure your android device will return read receipt.

Comment 8

[Gene Lian (I already quit Mozilla)]

Clear myself based on comment #6.

Comment 9

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8371354 [details] [review]
Link to github

Please check the github comment, thanks.

Comment 10

[Julien Wajsberg [:julienw]]

(In reply to Steve Chung [:steveck] from comment #7)
> Comment on attachment 8371354 [details] [review]
> Link to github
> 
> Hmm...the only thing need to do here is open the read receipt option in
> settings page and it should work on current master without any other trick.
> Please make sure both device flash to master with this patch, or make sure
> your android device will return read receipt.

I was sending a SMS to myself ;)

I'm building a new gecko and we'll see.

Comment 11

[Steve Chung [:steveck]]

Messageing settings updated. Although I think we don't need to hide these message options while airplane mode, it would be safer to discuss with Jose first. We will create another bug for this.

Comment 12

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8371354 [details] [review]
Link to github

r=me for the settings part. Thanks.

Comment 13

[Julien Wajsberg [:julienw]]

Comment on attachment 8371354 [details] [review]
Link to github

r=me

I'm so dumb, because I tried with SMS and not with MMS...

thanks Steve !

Comment 14

[Julien Wajsberg [:julienw]]

Mmm you have unit tests issues in settings (the calendar one seems unrelated), so please check it before merging.

Comment 15

[Steve Chung [:steveck]]

(In reply to Julien Wajsberg [:julienw] from comment #14)
> Mmm you have unit tests issues in settings (the calendar one seems
> unrelated), so please check it before merging.

Thanks for the reminder, I'll commit a test-fixing pitch for Arthur soon!

Comment 16

[Steve Chung [:steveck]]

Comment on attachment 8371354 [details] [review]
Link to github

Hi Arthur, I added some fixing in messaging_test. Sorry for bothering you again...

Comment 17

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8371354 [details] [review]
Link to github

r=me. Thanks!

Comment 18

[Steve Chung [:steveck]]

Thanks for all the review!
Landed in master: 14a578d181e76d9fd763d16ef2c23c20d00a9b16

Comment 19

[Axel Hecht [:Pike]]

I find

Request read report for each message sent

hard to understand in English. I know that this showed up in wireframes a lot, but is this the best English string we can get?

Comment 20

[Julien Wajsberg [:julienw]]

Axel, can you file a new bug? I'm sure we can do better, we can ask Tyler Altes about this.

Comment 21

[Matej Novak [:matej]]

(In reply to Axel Hecht [:Pike] from comment #19)
> I find
> 
> Request read report for each message sent
> 
> hard to understand in English. I know that this showed up in wireframes a
> lot, but is this the best English string we can get?

I think adding "a" makes it more clear:

Request a read report for each message sent

Comment 22

[Julien Wajsberg [:julienw]]

Tyler, could you please proofread this text (ref: comment 19 and comment 21) ?

Thanks !

Comment 23

[tyler.altes]

Hi, I would actually change most of the language around this function. 

First, a question to make sure I understand: When we say "request notification of delivery", do they actually receive a notification or just a green checkmark within the message details when they open the message/status?

For wording, instead of "Delivery" and "Read", I would talk about "Sent" and "Opened". And then, the concept of a "report" and "requesting a report" sounds confusing and technical. Here's how I would put the texts: 

For the Settings screen - https://bug919974.bugzilla.mozilla.org/attachment.cgi?id=8336259:

"Delivery Report" -> "Notify when sent"
"You'll see a check when a message is sent successfully."

"Read Report" -> "Notify when opened"
"You'll see a check when a message you sent is opened."


And on this screen - https://bug919974.bugzilla.mozilla.org/attachment.cgi?id=8336260:

"Message Report" -> "Message Details"

"Delivery: 05th october 2013 at 11:45" -> "Sent: 5 October 2013 at 11:45"

"Read: Report requested" -> "Opened: pending"

Hope all this is clear. Let me know if you need more feedback.

Comment 24

[Matej Novak [:matej]]

I would make a couple of small tweaks:

"Delivery Report" -> "Notify when sent"
"You'll see a check mark when your message is sent successfully."

"Read Report" -> "Notify when opened"
"You'll see a check mark when the message you sent is opened."

My only concern is how well "check mark" is going to localize.

Comment 25

[Axel Hecht [:Pike]]

a) what do we do with this bug? Back out and re-land with the right strings?

b) I think we can create a localization note for "You'll see a check mark..." explaining that there's a green check mark icon appearing next to message. It should be possible to find a phrase for that, independent of the word check mark.

Comment 26

[tyler.altes]

I agree with Matej that it's a bit clearer saying "check mark", but I wanted to keep it within the same character count as the previous message. If the phrase fits with "mark", even better.

And Axel's right. If the translators know what we're referring to, they should be able to find a way to explain it, even if they don't translate a direct name for check mark. Another option would be to use the symbol instead of the word: "You'll see a √ when your message is sent successfully." Not sure how practical it is on a technical/font level...

Comment 27

[Julien Wajsberg [:julienw]]

(In reply to tyler.altes from comment #23)
> Hi, I would actually change most of the language around this function. 
> 
> First, a question to make sure I understand: When we say "request
> notification of delivery", do they actually receive a notification or just a
> green checkmark within the message details when they open the message/status?

The green checkmark, and it's also displayed when displaying a message details.


> For wording, instead of "Delivery" and "Read", I would talk about "Sent" and
> "Opened". And then, the concept of a "report" and "requesting a report"
> sounds confusing and technical. Here's how I would put the texts: 
> 
> For the Settings screen -
> https://bug919974.bugzilla.mozilla.org/attachment.cgi?id=8336259:
> 
> "Delivery Report" -> "Notify when sent"
> "You'll see a check when a message is sent successfully."

The issue is that it's not exactly this.
"Delivery" means the network has distributed the message to the final user. This is sent by the network (if I'm not wrong).
"Read" means the user has read the message. On some devices, the user may prevent this from happening. Some devices may even not support this, which means they would not send a read report at all.

> 
> "Read Report" -> "Notify when opened"
> "You'll see a check when a message you sent is opened."
> 
> 
> And on this screen -
> https://bug919974.bugzilla.mozilla.org/attachment.cgi?id=8336260:
> 
> "Message Report" -> "Message Details"
> 
> "Delivery: 05th october 2013 at 11:45" -> "Sent: 5 October 2013 at 11:45"

same comment

> 
> "Read: Report requested" -> "Opened: pending"
> 
> Hope all this is clear. Let me know if you need more feedback.

Other than that, I like this. (I'll still want Ayman to come and say "fine").


(In reply to Axel Hecht [:Pike] from comment #25)
> a) what do we do with this bug? Back out and re-land with the right strings?

Another bug please. Especially that the delivery report part landed a loooooong time ago.


Thanks to all for your dedication!

Comment 28

[Axel Hecht [:Pike]]

My problem is that I can't really publish the strings on gaia master like this, so this is blocking l10n of 1.4 at this point.

And I don't think that 2014-02-18 (landing date) is looooong time ago.

Comment 29

[Julien Wajsberg [:julienw]]

Axel: this bug was only about the read reports feature. The delivery report feature landed a loooooooooooong time ago (bug 933131 in Messages, I don't know for the Settings part). That's what I meant.

Since we want to change all strings, this needs another bug. We can't backout the delivery reports.

Also, a precision:

> First, a question to make sure I understand: When we say "request
> notification of delivery", do they actually receive a notification or just a
> green checkmark within the message details when they open the message/status?

Actually, my bad, Bug 933133 will implement a real notification for these. We'll probably need to have your help on the l10n strings there too.

Comment 30

[tyler.altes]

> > "Delivery Report" -> "Notify when sent"
> > "You'll see a check when a message is sent successfully."
> 
> The issue is that it's not exactly this.
> "Delivery" means the network has distributed the message to the final user.
> This is sent by the network (if I'm not wrong).
> "Read" means the user has read the message. On some devices, the user may
> prevent this from happening. Some devices may even not support this, which
> means they would not send a read report at all.
> 

Based on your description, I still think that "Sent" and "Opened" are the right words to use to describe this to the user. However, the concept that the info won't always be available needs to be a bit clearer. I think it is difficult to make this clear within the texts describing the ON/OFF switch for reports. So, a couple suggestions:

1. If we have a way to know when a sent/opened report is requested but not available, then we should create 3 types of status in the Message Details: "Pending" (report is requested, but we don't have any answer yet), "No info available" (report was requested, but was not received), "5 October 2013 at 11:45" (report received). This way, we don't need to explain a priori that sometimes info won't be available. It will simply be clear (and a standard occurrence in lots of similar messaging contexts) that data could not be retrieved about this message.

2. If we don't have a way to distinguish reports that are requested and still pending from reports that are requested but never going to be received, it's a bit more complicated. My suggestion would be to add a note somewhere that gives a general warning that data is not always available. Maybe on the Settings screen just below the report ON/OFF options, and on the Message Details screen just below the statuses, something like: "It's not always possible to confirm when sent/opened."



In other news, and to avoid disappearing suddenly, I wanted to let you know that this will be my last response on bugzilla. My last day at Telefónica is this Friday and I've been asked to focus exclusively on other projects with my remaining time. Good luck to you all with the continued progress on FFOS!

Comment 31

[Julien Wajsberg [:julienw]]

(In reply to tyler.altes from comment #30)
> > > "Delivery Report" -> "Notify when sent"
> > > "You'll see a check when a message is sent successfully."
> > 
> > The issue is that it's not exactly this.
> > "Delivery" means the network has distributed the message to the final user.
> > This is sent by the network (if I'm not wrong).
> > "Read" means the user has read the message. On some devices, the user may
> > prevent this from happening. Some devices may even not support this, which
> > means they would not send a read report at all.
> > 
> 
> Based on your description, I still think that "Sent" and "Opened" are the
> right words to use to describe this to the user.

about "Sent" I'm a bit concerned. Let me explain. There are IMO 4 states for a message after the user presses the "sent" button:
1. pending
2. sent (ie, the network got the message)
3. delivered to the other device by the network
4. read by the receiver

Delivery report is about 3, Read report is about 4. If we use "Sent", it means the 2nd state to me.

>  However, the concept that
> the info won't always be available needs to be a bit clearer. I think it is
> difficult to make this clear within the texts describing the ON/OFF switch
> for reports. So, a couple suggestions:
> 
> 1. If we have a way to know when a sent/opened report is requested but not
> available, then we should create 3 types of status in the Message Details:
> "Pending" (report is requested, but we don't have any answer yet), "No info
> available" (report was requested, but was not received), "5 October 2013 at
> 11:45" (report received). This way, we don't need to explain a priori that
> sometimes info won't be available. It will simply be clear (and a standard
> occurrence in lots of similar messaging contexts) that data could not be
> retrieved about this message.
> 
> 2. If we don't have a way to distinguish reports that are requested and
> still pending from reports that are requested but never going to be
> received, it's a bit more complicated. My suggestion would be to add a note
> somewhere that gives a general warning that data is not always available.
> Maybe on the Settings screen just below the report ON/OFF options, and on
> the Message Details screen just below the statuses, something like: "It's
> not always possible to confirm when sent/opened."

I think we don't have a way to distinguish. I'm not sure this is that important though, but this is Ayman's call, thus I NI him.

> 
> In other news, and to avoid disappearing suddenly, I wanted to let you know
> that this will be my last response on bugzilla. My last day at Telefónica is
> this Friday and I've been asked to focus exclusively on other projects with
> my remaining time. Good luck to you all with the continued progress on FFOS!

Oh it's so sad, thanks so much for your help with us! We'll need to find someone as valuable as you, will be tough ;)

Comment 32

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #31)
> (In reply to tyler.altes from comment #30)
> >  However, the concept that
> > the info won't always be available needs to be a bit clearer. I think it is
> > difficult to make this clear within the texts describing the ON/OFF switch
> > for reports. So, a couple suggestions:
> > 
> > 1. If we have a way to know when a sent/opened report is requested but not
> > available, then we should create 3 types of status in the Message Details:
> > "Pending" (report is requested, but we don't have any answer yet), "No info
> > available" (report was requested, but was not received), "5 October 2013 at
> > 11:45" (report received). This way, we don't need to explain a priori that
> > sometimes info won't be available. It will simply be clear (and a standard
> > occurrence in lots of similar messaging contexts) that data could not be
> > retrieved about this message.
> > 
> > 2. If we don't have a way to distinguish reports that are requested and
> > still pending from reports that are requested but never going to be
> > received, it's a bit more complicated. My suggestion would be to add a note
> > somewhere that gives a general warning that data is not always available.
> > Maybe on the Settings screen just below the report ON/OFF options, and on
> > the Message Details screen just below the statuses, something like: "It's
> > not always possible to confirm when sent/opened."
> 
> I think we don't have a way to distinguish. I'm not sure this is that
> important though, but this is Ayman's call, thus I NI him.

no to the best of my knowledge we cannot distinguish between requests that are pending and requests that will never be recieved.  

> > In other news, and to avoid disappearing suddenly, I wanted to let you know
> > that this will be my last response on bugzilla. My last day at Telefónica is
> > this Friday and I've been asked to focus exclusively on other projects with
> > my remaining time. Good luck to you all with the continued progress on FFOS!
> 
> Oh it's so sad, thanks so much for your help with us! We'll need to find
> someone as valuable as you, will be tough ;)

:(

Comment 33

[Julien Wajsberg [:julienw]]

(In reply to ayman maat :maat from comment #32)

> > > 2. If we don't have a way to distinguish reports that are requested and
> > > still pending from reports that are requested but never going to be
> > > received, it's a bit more complicated. My suggestion would be to add a note
> > > somewhere that gives a general warning that data is not always available.
> > > Maybe on the Settings screen just below the report ON/OFF options, and on
> > > the Message Details screen just below the statuses, something like: "It's
> > > not always possible to confirm when sent/opened."
> > 
> > I think we don't have a way to distinguish. I'm not sure this is that
> > important though, but this is Ayman's call, thus I NI him.
> 
> no to the best of my knowledge we cannot distinguish between requests that
> are pending and requests that will never be recieved.  

Ayman, then, what do you think about Tyler's suggestion? do you think we need it?

Comment 34

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #33)
> (In reply to ayman maat :maat from comment #32)
> 
> > > > 2. If we don't have a way to distinguish reports that are requested and
> > > > still pending from reports that are requested but never going to be
> > > > received, it's a bit more complicated. My suggestion would be to add a note
> > > > somewhere that gives a general warning that data is not always available.
> > > > Maybe on the Settings screen just below the report ON/OFF options, and on
> > > > the Message Details screen just below the statuses, something like: "It's
> > > > not always possible to confirm when sent/opened."
> > > 
> > > I think we don't have a way to distinguish. I'm not sure this is that
> > > important though, but this is Ayman's call, thus I NI him.
> > 
> > no to the best of my knowledge we cannot distinguish between requests that
> > are pending and requests that will never be recieved.  
> 
> Ayman, then, what do you think about Tyler's suggestion? do you think we
> need it?

Its a good user centred proposal from Tyler, but I don't think we *need* it because other systems do not provide such guidance and i think there is a push on in Moz to reduce the amount of copy on the interfaces of the phone. However if there is desire to have such guidance, I would not argue against it.

Comment 35

[Julien Wajsberg [:julienw]]

(putting a NI to myself to remember to file a bug about changing the string, with a summary of this discussion)

Comment 36

[Julien Wajsberg [:julienw]]

Filed Bug 977081 for Settings.
Filed Bug 977088 for Messages.