977081 - [Settings] Change the texts for delivery/read reports

Status: RESOLVED WONTFIX

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

Description

[Julien Wajsberg [:julienw]]

From Bug 926852 comment 23, 24, 26:

"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."


I'm still not sure about the term "sent" because the report is sent by the network once the network delivered the message to the recipient. Ayman, what do you think?

Comment 1

[Steve Chung [:steveck]]

Like bug 977088 comment 1 I would perfer to keep 'Delivery' instead of sent, but I agree we can have better description about the Delivery/Read. Please note we might remove the check mark in the message bubble in the future, and Ayman is re-designing this part.

Comment 2

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #0)
> From Bug 926852 comment 23, 24, 26:
> 
> "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."
> 
> 
> I'm still not sure about the term "sent" because the report is sent by the
> network once the network delivered the message to the recipient. Ayman, what
> do you think?

Please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=977088#c2 which is directly related to this for my response to this bug. 

but fundamentally i agree with you and steve: we should absolutely not use 'Sent' for 'Delivery', and better descriptions in settings would help.

Comment 3

[Preeti Raghunath(:Preeti)]

Wouldn't block release 1.4 on this. Moving to 1.5 for tracking

Comment 4

[Julien Wajsberg [:julienw]]

Requesting 1.4 again, sorry, this was asked by the l10n team in Bug 926852 comment 23.

NI Pike to give more information about why this should block.

Comment 5

[Julien Wajsberg [:julienw]]

And this is not especially a risky nor difficult change.

Comment 6

[Axel Hecht [:Pike]]

I don't think that l10n is the driver here, but UX is.

The story of bug 977088 applies to this bug, too, they're the same thing, just in different apps.

Comment 7

[Julien Wajsberg [:julienw]]

Ayman, need you to say whether the other changes are a blocker for you in 1.4.
(it is for me).

Comment 8

[Matej Novak [:matej]]

Just to be clear, are we proposing "Notify when delivered" for the first one?

Comment 9

[Julien Wajsberg [:julienw]]

Yes, I think this would be :

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

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

Comment 10

[Julien Wajsberg [:julienw]]

Or as Ayman said on the other bug, keep "read" instead of "opened" because of the prior art.

Comment 11

[Matej Novak [:matej]]

(In reply to Julien Wajsberg [:julienw] from comment #9)
> Yes, I think this would be :
> 
> "Delivery Report" -> "Notify when delivered"
> "You'll see a check mark when your message is delivered successfully."
> 
> "Read Report" -> "Notify when opened"
> "You'll see a check mark when the message you sent is opened."

Thanks. Maybe we could make the following tweaks for consistency:

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

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

Comment 12

[Matej Novak [:matej]]

(In reply to Julien Wajsberg [:julienw] from comment #10)
> Or as Ayman said on the other bug, keep "read" instead of "opened" because
> of the prior art.

If "read" is standard I'm OK using it, but "opened" feels more accurate.

Comment 13

[Steve Chung [:steveck]]

(In reply to Matej Novak [:matej] from comment #12)
> (In reply to Julien Wajsberg [:julienw] from comment #10)
> > Or as Ayman said on the other bug, keep "read" instead of "opened" because
> > of the prior art.
> 
> If "read" is standard I'm OK using it, but "opened" feels more accurate.

How about we keep the "read" for title and use "You'll see a check mark when your message is opened." for description? Showing these 2 terms together shouldn't so misleading and user could get more clear idea about the meaning of "read from the description.

Comment 14

[ayman maat :maat]

(In reply to Matej Novak [:matej] from comment #11)
> (In reply to Julien Wajsberg [:julienw] from comment #9)
> > Yes, I think this would be :
> > 
> > "Delivery Report" -> "Notify when delivered"
> > "You'll see a check mark when your message is delivered successfully."
> > 
> > "Read Report" -> "Notify when opened"
> > "You'll see a check mark when the message you sent is opened."
> 
> Thanks. Maybe we could make the following tweaks for consistency:
> 
> "Delivery Report" -> "Notify when delivered"
> "You'll see a check mark when your message is delivered."
> 
> "Read Report" -> "Notify when opened"
> "You'll see a check mark when your message is opened."

Well the problem is two things:

firstly that the user wont see a checkmark when the message is delivered or opened. Jose delivered a specification before Christmas that demonstrated we would inform the user of receipt of delivery or read report using words in the message thread itself... and this is what we should be following.

Secondly the user is informed of receipt of delivery and read report through other mechanisms other than a check mark (if we were using one), for example they are informed through the phones notification system.

In view of this I would advise to modify these string as follows so we have more flexibility in our communication:

"Delivery Report" -> "Notify when delivered"
"You'll be notified when your message is delivered."
 
"Read Report" -> "Notify when opened"
"You'll be notified when your message is opened."

Comment 15

[Preeti Raghunath(:Preeti)]

UX,

Can we please fix this in 1.5 instead?

Comment 16

[Stephany Wilkes]

A string change like this would make for late L10N, no? 

I do not think this is a blocker but should definitely be fixed for 1.5/2.0. We are doing a huge copy audit and update this year so this will fit nicely.

Comment 17

[Axel Hecht [:Pike]]

We're not in late-l10n land until march 17 and code freeze, at least according to the schedules I've seen.

Comment 18

[Preeti Raghunath(:Preeti)]

Backlog 

Per UX

Comment 19

[BMO Automation]

Firefox OS is not being worked on