User Story: As a user I want to be able to request read receipt for sms and mms. Acceptance Criteria: AC 1: As a user I expect to be able to set this up independently for SMS and MMS. AC 2: As a user I want a location to define default options for requesting read receipts AC 3: As a user I want to be able to define it on a per message basis. As a user I want to the per message basis configuration to override the default configuration.

Change in-moztrap tag and start to work on test cases

Hi Wilfred, some user stories sound weird to Steve and me. Could you please clarify them? Thanks! (In reply to Wilfred Mathanaraj [:WDM] from comment #0) > User Story: > > As a user I want to be able to request read receipt for sms and mms. > > > Acceptance Criteria: > > AC 1: As a user I expect to be able to set this up independently for SMS and > MMS. This one doesn't work. Read report is only available on MMS. SMS is not capable of handling read report. > AC 2: As a user I want a location to define default options for requesting > read receipts We can do this through a setting entry in the Settings App. > AC 3: As a user I want to be able to define it on a per message basis. As a > user I want to the per message basis configuration to override the default > configuration. This one doesn't make sense. As a sender, users will just hope to set it one time in the Settings App (AC 2) to request read reports for all the messages. I don't see many benefits by setting it per message, which is very annoying to the users. I think the thing we want to do per message basis is: as a receiver, user can decide if he or she wants to return the read port to the sender for a given message.

(In reply to Gene Lian [:gene] (Summit + PTOs 10/3 ~ 10/14) from comment #3) > Hi Wilfred, some user stories sound weird to Steve and me. Could you please > clarify them? Thanks! > > (In reply to Wilfred Mathanaraj [:WDM] from comment #0) > > User Story: > > > > As a user I want to be able to request read receipt for sms and mms. > > > > > > Acceptance Criteria: > > > > AC 1: As a user I expect to be able to set this up independently for SMS and > > MMS. > > This one doesn't work. Read report is only available on MMS. SMS is not > capable of handling read report. > I think this information is important for UX. Hi Ayman, since the behavior is different from delivery report, you might need to consider whether we should have more description in option because it's mms-only option. > > AC 2: As a user I want a location to define default options for requesting > > read receipts > > We can do this through a setting entry in the Settings App. > > > AC 3: As a user I want to be able to define it on a per message basis. As a > > user I want to the per message basis configuration to override the default > > configuration. > > This one doesn't make sense. As a sender, users will just hope to set it one > time in the Settings App (AC 2) to request read reports for all the > messages. I don't see many benefits by setting it per message, which is very > annoying to the users. This feature means we need to make a room for read report option in message compose page(and it only shows up in mms mode) and user might get confused because there is no way to classify that the message is not read yet or they didn't set the read report request when message sent. It seems not a very pleasant feature for user... Hi Ayman, do you have any idea for this feature? It will involve many UX changes here. > > I think the thing we want to do per message basis is: as a receiver, user > can decide if he or she wants to return the read port to the sender for a > given message.

Ah! I originally wanted to needinfo from Wilfred. It was my mistake. Hi Wilfred, could you please take a look at comment #3? Thanks!

I don't see your problem with AC3. I think it makes sense to either: * disable the read report for a specific message, if it is enabled by default * enable the read report for a specific message, if it is disabled by default I agree this could be done later though. About AC1, I'm quite sure to have seen read report for SMS, back in the time when I used feature phones. Are you sure it doesn't exist ? Maybe it's implemented quite differently ?

(In reply to Steve Chung [:steveck] from comment #4) > (In reply to Gene Lian [:gene] (Summit + PTOs 10/3 ~ 10/14) from comment #3) > > Hi Wilfred, some user stories sound weird to Steve and me. Could you please > > clarify them? Thanks! > > > > (In reply to Wilfred Mathanaraj [:WDM] from comment #0) > > > User Story: > > > > > > As a user I want to be able to request read receipt for sms and mms. > > > > > > > > > Acceptance Criteria: > > > > > > AC 1: As a user I expect to be able to set this up independently for SMS and > > > MMS. > > > > This one doesn't work. Read report is only available on MMS. SMS is not > > capable of handling read report. > > > I think this information is important for UX. Hi Ayman, since the behavior > is different from delivery report, you might need to consider whether we > should have more description in option because it's mms-only option. I do not find precedence for a Read Report for SMS on any of my reference phones. Is it even possible to request and receive a read report for SMS? ni? to Wilfred to confirm if this is feature that is required > > > AC 3: As a user I want to be able to define it on a per message basis. As a > > > user I want to the per message basis configuration to override the default > > > configuration. > > > > This one doesn't make sense. As a sender, users will just hope to set it one > > time in the Settings App (AC 2) to request read reports for all the > > messages. I don't see many benefits by setting it per message, which is very > > annoying to the users. > This feature means we need to make a room for read report option in message > compose page(and it only shows up in mms mode) and user might get confused > because there is no way to classify that the message is not read yet or they > didn't set the read report request when message sent. It seems not a very > pleasant feature for user... Hi Ayman, do you have any idea for this > feature? It will involve many UX changes here. Ok so from a UX perspective I have modelled this several times now and, within the framework of our current building blocks an patterns it is incredibly confusing/disorientating to allow the user to make the setting globally and then allow the user to 'customise' it on a per message basis. We would need significant rework of the interaction and visual architecture of the messages app (resulting in alteration of patters) in order to accommodate this, and even then its still not comfortable. I would therefore recommend that we left this to a later version. However in oder to fulfil this requirement my prescription for V1.3 would be to allow access to the Global Message Setting that currently sits within the Settings app (Settings > Celluar & Data > Message Settings) from within the Compose New Message dialogue and the Message thread view. It would be good if we could provide an instance (for want of a better word) of this Settings interface in 'isolation' so that cancelling it would return the user to the interface from which it was launched rather than leaving them in the Settings app itself.

Ok - sounds AC3 is getting far too complicated to implement - lets remove AC3 for v1.3. I will add AC3 as a new user story for a future release.

AC1> I maybe mixed read report with delivery report, sorry.

Having talked to Ayman: AC1: I am fine to support for MMS only. AC3: can we enable access to the message settings area from new message composer and thread view? will that solve the problem?

(In reply to Wilfred Mathanaraj [:WDM] from comment #10) > Having talked to Ayman: > > AC1: I am fine to support for MMS only. > AC3: can we enable access to the message settings area from new message > composer and thread view? will that solve the problem? About AC3: If we want to access message settings panel from message app, we can open the settings app and switch to message settings panel. But settings app does not support inline activity yet, that means we could not switch back to message app directly. It's not quite convenient for user now(we could still implement this feature if ux accepts this flaw).

Actually a "window" activity can now return back to the caller :) What it can't do is stack up contexts: you can't call another activity from there, and expect that going back will work as expected.

(In reply to Julien Wajsberg [:julienw] from comment #12) > Actually a "window" activity can now return back to the caller :) > > What it can't do is stack up contexts: you can't call another activity from > there, and expect that going back will work as expected. Just confirmed with Alive, returning from window dispositioned activity is working now(seems no one give it a try yet). But it need some effort to handle the settings app context: it should be able to distinguish the app is triggered by webactivity or not, and handle the different context entry correctly(the limitation you metion is also another noticeable behavior). If we really want to config delivery/read report from message app, we can have settings options in message app since not all the message settings is required within per message configuration(like message apn settings).

(In reply to Steve Chung [:steveck] from comment #13) > (In reply to Julien Wajsberg [:julienw] from comment #12) > > Actually a "window" activity can now return back to the caller :) > > > > What it can't do is stack up contexts: you can't call another activity from > > there, and expect that going back will work as expected. > > Just confirmed with Alive, returning from window dispositioned activity is > working now(seems no one give it a try yet). But it need some effort to > handle the settings app context: it should be able to distinguish the app is > triggered by webactivity or not, and handle the different context entry > correctly(the limitation you metion is also another noticeable behavior). > > If we really want to config delivery/read report from message app, we can > have settings options in message app since not all the message settings is > required within per message configuration(like message apn settings). Hey steve. We do need to allow the user access to config delivery/read report from the message app itself ...We also need to move the Message specific settings out of the setting app and into the messages app at some point. (Rob, Casey and others pointed out to me that we had broken our OS convention by deciding to put them in the Settings app whilst in Portland). I don't mind when we do this, its really down to your bandwidth. Therefore at this point we can either use a 'window' activity to 'deep link' (for want of a better phrase) to the message settings within the settings app as Julien suggested, or actually bring the message settings out of the settings app and into the messages app now. I would obviously prefer to bring the settings into the messages app as it simultaneously settles an old UX issue, but its really up to you and what you feel we can achieve in the time we have as to which path we follow. ni? to steve and julien to provide guidance on which path is feasible to follow so i can close the specifications accurately on for this bug.

I think moving settings should be a bug by itself, there are technical issues to discuss.

To be clearer: if the settings needs to be kept inside the Messages app, then I see no problem with doing it. If the settings needs to be read by Gecko, then we need to add the readwrite permission for the Settings API for the Messages app, and I'm not sure we should do that. (but maybe that's not a big deal and we could just do it).

(In reply to Julien Wajsberg [:julienw] from comment #16) > To be clearer: if the settings needs to be kept inside the Messages app, > then I see no problem with doing it. If the settings needs to be read by > Gecko, then we need to add the readwrite permission for the Settings API for > the Messages app, and I'm not sure we should do that. (but maybe that's not > a big deal and we could just do it). We definatly need settings readwrite permission in message app if we really want to move message settings into message app. As a certified app I don't think it's a serious issue to change the permission. Both methods need efforts to fit requirement: 1) Open settings app to config message related settings: Less changes in message app, but need settings app's help to control activity status. It's a non-trivial task to settings app and they didn't plan this for 1.3. I need further discussion with settings app peer about this solution. 2) Implement settings panel inside message app: Need to move message settings panel from settings to message app. It's easier to just clean up the settings page but need more efforts to build a new page. It also comes out another problem: Should we also need to move message apn settings into message app? All the apn settings were in call settings page(including message apn settings) and reuse the same code base to search the apn database and display the correct value. If we also move the message apn settings into message app, we will duplicate codea and database inside the message app. I don't think it's a fesible way for doing this. I would prefer to move other message related settings inside the message app and leave apn settings inside settings app. User has rare chance to chages message apn frequently, but it will require more resource in message app. If moving the message settings inside the app itself is future goal for sure, we had better start implemetation now. But I would suggest to keep the apn inside the settings app, thanks.

(In reply to Steve Chung [:steveck] from comment #17) > (In reply to Julien Wajsberg [:julienw] from comment #16) > 2) Implement settings panel inside message app: Need to move message > settings panel from settings to message app. It's easier to just clean up > the settings page but need more efforts to build a new page. It also comes > out another problem: Should we also need to move message apn settings into > message app? All the apn settings were in call settings page(including > message apn settings) and reuse the same code base to search the apn > database and display the correct value. If we also move the message apn > settings into message app, we will duplicate codea and database inside the > message app. I don't think it's a fesible way for doing this. I would prefer > to move other message related settings inside the message app and leave apn > settings inside settings app. User has rare chance to chages message apn > frequently, but it will require more resource in message app. > > If moving the message settings inside the app itself is future goal for > sure, we had better start implemetation now. But I would suggest to keep the > apn inside the settings app, thanks. form the UX side I totally agree that APN should stay in the settings app. We should move only the message related settings inside the message app and leave APN where it is. ni? to Julien and Steve: Could I request we reach agreement on which path to follow so that i can close the specs accurately?

> As a certified app I don't think it's a serious issue to change the permission. This is not a big deal technically, but adding a new permission is never good. I just asked Vivien actually, and he agrees with me here. So here is my proposal (which could/should be a separate bug by the way): * we won't use a global setting for this (it means that we'll always give Gecko the optional arguments) * we will keep these settings in a local indexedDB stored in the Messages app Does that sound good Steve ?

(In reply to Julien Wajsberg [:julienw] from comment #19) > So here is my proposal (which could/should be a separate bug by the way): > * we won't use a global setting for this (it means that we'll always give > Gecko the optional arguments) > * we will keep these settings in a local indexedDB stored in the Messages app > > Does that sound good Steve ? Sorry for jumping in here, but just want to be sure that we are all in the same page. What you are proposing will create the sms/mms specific settings inside of the message app, and will be inaccessible from other apps, right? So if that's the case, we are assuming that any other app installed on the system that deals with messages will behave differently when dealing with those settings. Is this a valid behaviour from a technical and UX point of view?

(In reply to Fernando Campo (:fcampo) from comment #20) > (In reply to Julien Wajsberg [:julienw] from comment #19) > > So here is my proposal (which could/should be a separate bug by the way): > > * we won't use a global setting for this (it means that we'll always give > > Gecko the optional arguments) > > * we will keep these settings in a local indexedDB stored in the Messages app > > > > Does that sound good Steve ? > > Sorry for jumping in here, but just want to be sure that we are all in the > same page. What you are proposing will create the sms/mms specific settings > inside of the message app, and will be inaccessible from other apps, right? > So if that's the case, we are assuming that any other app installed on the > system that deals with messages will behave differently when dealing with > those settings. > > Is this a valid behaviour from a technical and UX point of view? Hey Fernando There is totally no problem jumping in here and asking such a question. Its an excellent question to ask. As a bit of history the request to move the settings into the app originally comes from Moz UX. I have already today contacted Josh directly to get clarity on if this is really what is desired and how it is envisaged that Settings will work with multiple message apps. I will let you all know when i get a response.

Ok guys. I have had a conversation with Josh and Rob and in summary there is a general understanding now that, with reference to the excellently raised comment 20, it would not be an optimal idea to move Message Settings out of the Settings app at this point in time. Therefore with reference to comment 17 could we explore options 1) > 1) Open settings app to config message related settings: Less changes in message app, but need settings app's help to > control activity status. It's a non-trivial task to settings app and they didn't plan this for 1.3. I need further > discussion with settings app peer about this solution. Sorry for the U Turn

Seems we got the conclusion here, but I just want to explain the possible problem for having a local settings in message app: It might works for delivery/read report even UX agree we could keep different local settings in multiple message apps, the biggest problem is mms retrival mode. Download mechanism depends on global settings value, and it seems not possible to handle message download based on local settings. bug 924409 already stressed the requirement about opening the settings app from message, let's focus on the read report api/spec here and discuss the the activity behavior in bug 924409.

In my previous proposal, we could have both local settings handled in the Messages app and global settings handled in the Settings app. The goal is totally to let different Messages app have different behaviors. One longer term goal (for Vivien and Jonas at least) is to let apps expose their settings through some mean, for example datastores, so that it could be controlled from both the app and the Settings app, but this is long term ;)

That said, I'm perfectly happy with the first solution with keeping everything in Settings for now.

(In reply to Julien Wajsberg [:julienw] from comment #25) > That said, I'm perfectly happy with the first solution with keeping > everything in Settings for now. based on the conversation i had last night, i think that might be the best option in the short and long term.

Ok so in comment 0 of this bug we have requirements for setting read reports for outgoing messages. I would just like to confirm that the definition of the user experience for the receipt of an incoming message with a read report request associated to it is out of scope for v1.3 ni? to wilfred.

On the receiving side to allow a user to allow or reject read receipts are not in plan for v1.3 - they are in backlog and will be planned in for future release. We need it to be handled gracefully in v1.3 when a message is received with attached read receipts. I would say handle it gracefully and ignore the request for v1.3 and implement the support of this in v1.4

**Release Note** new wireframes - none updated wireframes - none deleted wireframes - none new flows - Forward Message : Message from thread - Delivery / Read report : Setting reports from within phone settings - Delivery / Read report : Setting reports from message app inbox - Delivery / Read report : Setting reports from within new message - Delivery / Read report : Setting reports from within message thread - Delivery / Read report : View report from thread - Delivery / Read report : View delivery report from notification - Delivery / Read report : View read report from notification - Message Module Interactions : Long press and MMS - Message Module Interactions : Tap on email address and MMS - Message Module Interactions : Tap on url and MMS - Message Module Interactions : Tap on phone number and MMS - Anonymous messages : Thread updated flows - none deleted flows - none pages relevant to this bug: 18, 20

Hi Rick, based on the previous sprint planing read receipts feature was assigned to me. The reason I left the assignee open is because this user story is based on ux/gecko/gaia integrated work. I will open other small tasks for gaia implementation if needed. Please ping me if you or your member is also interested in and has free cycle for some help, thanks.

(In reply to Steve Chung [:steveck] from comment #30) > Hi Rick, based on the previous sprint planing read receipts feature was > assigned to me. The reason I left the assignee open is because this user > story is based on ux/gecko/gaia integrated work. I will open other small > tasks for gaia implementation if needed. Please ping me if you or your > member is also interested in and has free cycle for some help, thanks. No problem, I had taken it for "admin" purposes ;)

**Release note*** new wireframes - Subject : maximum length of subject reached - Subject : maximum length of message reached - Subject : subject field - Message report : outgoing message report updated wireframes - none deleted wireframes - none new flows - Message report : View report for received message updated flows Delivery / Read report : Setting reports from within phone settings renamed: ‘Message report : Setting reports from within phone settings’ Delivery / Read report : Setting reports from message app inbox renamed: ’Message report : Setting reports from message app inbox’ Delivery / Read report : Setting reports from within new message renamed: ‘Message report : Setting reports from within new message’ Delivery / Read report : Setting reports from within message thread renamed: ’Message report : Setting reports from within message thread’ Delivery / Read report : View report from thread renamed: ‘Message report : View report for outgoing message from thread’ - ‘View message details’ CTA removed from frame ‘2. Message module options menu’ - annotation to frame ‘3. Message Report’ updated to reflect agreement in email thread Delivery / Read report : View delivery report from notification renamed: ’Message report : View delivery report from notification’ Delivery / Read report : View read report from notification renamed: ‘Message report : View read report from notification’ deleted flows - none

Hi everyone, Visual design related to Message Reports is ready. Please, ask me if you have any question.

**Release note*** new wireframes - none updated wireframes - none deleted wireframes Drafts : Message thread Due to removal of specification for saving multiple drafts in a message thread Drafts : Draft message module options Screen obsolete due to removal of specification for saving multiple drafts in a message thread new flows - none updated flows Drafts : Save as draft from within messages app Removal of specification for saving multiple drafts in a message thread Drafts : Save as draft when navigating away from messages app Removal of specification for saving multiple drafts in a message thread Drafts : Opening draft messages from within thread Removal of specification for saving multiple drafts in a message thread deleted flows - none

In-moztrap+ by following test cases https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-tag=2534

ni? Steve Base on your comment, bug 926852 has already implemented it. Can you please confirm and see if we still need to land the dependencies to satisfy the acceptance criteria? i feel we can resolve fixed this. thanks clear flag

I think we can close it first. These remaining features didn't block the read report functionality.

per comment 40: the functionality is finished, the remaining bugs are nice to have.