918558 - [B2G][DSDS][User Story] MMS handling for non-active subscription for DSDS

Status: VERIFIED FIXED

(Firefox OS Graveyard :: RIL, defect, P1)

Description

[Sandip Kamat]

As a user, if I receive a subscription#2 MMS message, while SIM/data is active on subscription#1, I should have a way to switch to subscription#2 to retrieve the MMS. (either "silently" or manually, per user's preference in settings)

Comment 1

[Kai-Chih Hu [:khu]]

We(Enpei, Carrie, Hsinyi, ...) made some testings on other DSDS phones, and found other phones provide manual configuration.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

The latest committed user story:

As a user, if I receive a subscription#2 MMS message, while SIM/data is active on subscription#1, I should have a way to switch to subscription#2 to retrieve the MMS. (manual)

Comment 3

[Enpei]

Acceptance criteria from PM:

1) This is a pretty straightforward use case when user received a text notification of an MMS on the network which is from a SIM that currently not-active. (e.g. SIM1 is chosen for data and MMS arrives for SIM2)

2) There should be an indication for the user to show that there is an MMS on an currently inactive (for data) SIM. 

3) Use UX guidance on notifying the user that they need to switch to the other SIM. Or at least indicate that the MMS will be accessible when the user switches the data to other SIM.

Comment 4

[Wilfred Mathanaraj [:WDM]]

The Acceptance Criteria need to match to the new user story for v1.3 as per comment #2.


(In reply to Enpei from comment #3)
> Acceptance criteria from PM:
> 
> 1) This is a pretty straightforward use case when user received a text
> notification of an MMS on the network which is from a SIM that currently
> not-active. (e.g. SIM1 is chosen for data and MMS arrives for SIM2)
> 

I dont get AC1.  - is there a need to indicate which SIM the MMS arrived on. This is not something we committed to v1.3.

> 2) There should be an indication for the user to show that there is an MMS
> on an currently inactive (for data) SIM. 

This was not agreed for v1.3 but for v1.4. The MMS or the MMS notification is displayed to the user. 
The implementation of which SIM the message/call arrived on was planned for v1.4 as per our meeting.

> 
> 3) Use UX guidance on notifying the user that they need to switch to the
> other SIM. Or at least indicate that the MMS will be accessible when the
> user switches the data to other SIM.

there is a dependency on the API to be able to inform comms on which SIM the message arrived to this to be implemented. this may not happen in v1.3 if the API is not fully tested and approved before implementation for this acceptance criteria.

 NI Sandip to confirm if my understanding is right on the points.

Comment 5

[Gene Lian (I already quit Mozilla)]

As far as I know, we don't need to worry about all the issues about the SIM card switching. Gecko will be in charge of constructing the MMS connection based on the MMS APN settings of that SIM card, when the device wants to download MMS (no matter its via automatic or manual download mode).

We don't need to design extra APIs, UXs/UIs or any implementations to support these user stories.

Vicamo, could you please correct me if I'm wrong? Thanks!

Comment 6

[Gene Lian (I already quit Mozilla)]

After discussing around with Hsin-yi and Vicamo, a possible approach is summarized as below:

Pre-condition: SIM_1 *enables* data connection and SIM_2 *disables* data connection.

1. When MMS retrieval mode == manual
   a. SIM_1 will pop up a notification. Users can then tap on the download button to download MMS.
   b. SIM_2 will pop up a notification. If users tap on the download button, Gaia needs to pop up a prompt to notify users: "please switch the data connection to SIM_2 before downloading MMS".

2. When MMS retrieval mode == automatic
   a. SIM_1 will directly download MMS without any notification.
   b. SIM_2 won't directly download MMS. Instead, SIM_2 will pop up a notification first. Then it goes to the case 1-b.

To do so, Gecko needs to change some internal downloading logic for case 2-b. Gaia needs to pop up a prompt for case 1-b.

Does that satisfy all the user stories we have?

Comment 7

[Wilfred Mathanaraj [:WDM]]

Does this involve any work on comms side to support the pop-ups?

Comment 8

[Gene Lian (I already quit Mozilla)]

If we decide to pop up something as suggested at comment #6 eventually, then I believe comms team has to be involved, including UI/UX/Gecko changes for case 1-b, and Gecko change for case 2-b.

Comment 9

[Ken Chang[:kenkai]]

(In reply to Gene Lian [:gene] (needinfo? encouraged) from comment #6)
> 2. When MMS retrieval mode == automatic
>    a. SIM_1 will directly download MMS without any notification.
>    b. SIM_2 won't directly download MMS. Instead, SIM_2 will pop up a
> notification first. Then it goes to the case 1-b.
In current single SIM design, MMS can be retrieved no matter what the configuration of data connection is. 
For 2-b, I wonder if we could follow single SIM design to directly retrieve the MMS.

Comment 10

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Ken Chang from comment #9)
> (In reply to Gene Lian [:gene] (needinfo? encouraged) from comment #6)
> > 2. When MMS retrieval mode == automatic
> >    a. SIM_1 will directly download MMS without any notification.
> >    b. SIM_2 won't directly download MMS. Instead, SIM_2 will pop up a
> > notification first. Then it goes to the case 1-b.
> In current single SIM design, MMS can be retrieved no matter what the
> configuration of data connection is. 
> For 2-b, I wonder if we could follow single SIM design to directly retrieve
> the MMS.

In that case, we would need to disconnect the current data connection on SIM1, silently set up MMS connection on SIM2. Not sure if this is the user experience we'd like to provide. Also, what about the subsequent actions? Should gecko automatically re-build data connection on SIM1? Or change the settings key to notify App the connection isn't there anymore? I am concerned if we want to support auto-retrieve for 2-b, it's error-prone and easily make gecko and gaia states out of sync...

Comment 11

[Stephany Wilkes]

Flagging Jacqueline to advise on the broader Comms UX impact here (if any), and flagging Carrie since she has done the existing DSDS spec, which I think is clear and probably doesn't require any further commentary.

Comment 12

[Sandip Kamat]

(In reply to Wilfred Mathanaraj [:WDM] from comment #4)
> The Acceptance Criteria need to match to the new user story for v1.3 as per
> comment #2.
> 
> 
> (In reply to Enpei from comment #3)
> > Acceptance criteria from PM:
> > 
> > 1) This is a pretty straightforward use case when user received a text
> > notification of an MMS on the network which is from a SIM that currently
> > not-active. (e.g. SIM1 is chosen for data and MMS arrives for SIM2)
> > 
> 
> I dont get AC1.  - is there a need to indicate which SIM the MMS arrived on.
> This is not something we committed to v1.3.
> 
> > 2) There should be an indication for the user to show that there is an MMS
> > on an currently inactive (for data) SIM. 
> 
> This was not agreed for v1.3 but for v1.4. The MMS or the MMS notification
> is displayed to the user. 
> The implementation of which SIM the message/call arrived on was planned for
> v1.4 as per our meeting.
> 
> > 
> > 3) Use UX guidance on notifying the user that they need to switch to the
> > other SIM. Or at least indicate that the MMS will be accessible when the
> > user switches the data to other SIM.
> 
> there is a dependency on the API to be able to inform comms on which SIM the
> message arrived to this to be implemented. this may not happen in v1.3 if
> the API is not fully tested and approved before implementation for this
> acceptance criteria.
> 
>  NI Sandip to confirm if my understanding is right on the points.

"Indicating SIM" part is okay to postpone to 1.4 as long as this user story is implemented for v1.3.

Comment 13

[Enpei]

update moztrap link.

Comment 14

[Kai-Chih Hu [:khu]]

Remove blocking-b2g flag from User Story bugs. Use whiteboard to indicate what FxOS version we target.

Comment 15

[Enpei]

Attachment: [SPEC] DSDS v0.7.pdf

Based on UX v0,7 spec, there is a confirmation window when user tries to download attachment of non-primary outgoing data SIM. The window will ask whether user would like to switch data to this SIM, if yes, outgoing data will be changed and attachment will be downloaded.

Just to make sure all related developers and PM are aware of this before we finally test the feature on device.

Comment 16

[Sandip Kamat]

(In reply to Enpei from comment #15)
> Created attachment 832785 [details]
> [SPEC] DSDS v0.7.pdf
> 
> Based on UX v0,7 spec, there is a confirmation window when user tries to
> download attachment of non-primary outgoing data SIM. The window will ask
> whether user would like to switch data to this SIM, if yes, outgoing data
> will be changed and attachment will be downloaded.
> 

will that be changed 1 time or permanently?

Comment 17

[Carrie Wang [New account: [e-mail]]]

(In reply to Sandip Kamat from comment #16)
> (In reply to Enpei from comment #15)
> > Created attachment 832785 [details]
> > [SPEC] DSDS v0.7.pdf
> > 
> > Based on UX v0,7 spec, there is a confirmation window when user tries to
> > download attachment of non-primary outgoing data SIM. The window will ask
> > whether user would like to switch data to this SIM, if yes, outgoing data
> > will be changed and attachment will be downloaded.
> > 
> 
> will that be changed 1 time or permanently?

The change will be permanent. If the user want to switch it back, he need to do it in SIM manager. Thanks!

Comment 18

[Jean Gong :jgong]

Update whiteboard tag to follow format [ucid:{id}, {release}:p{1,2}, ft:{team-id}]

Comment 19

[Ken Chang[:kenkai]]

All dependencies are close. Let's verify it.

Comment 20

[Enpei]

Test on Fugu
Gaia:     124f6b7105b86fc3f7a11aaf0a354abc93b36047
Gecko:    d3d3413a417302268344e1be2be03cfcaefd2ff0
BuildID   20131203063021
Version   28.0a1

link to bugs blocking or failing test cases.

Comment 21

[Jacqueline Savory [:jsavory] UX]

Clearing flag as this has been answered by Carrie.

Comment 22

[Enpei]

Verified on fugu 
Fugu
Gaia      ee25b0e45649d2955f340ce4f71ad55712dd0fab
Gecko     913cf2b92845441c9578787362ddad6f2ac15df6
BuildID   20140121095108
Version   28.0a2

Bug 961934 impact the user story that unable to switch data to non-primary data SIM to download attachment.

Comment 23

[Enpei]

Verified on Fugu.
Passed.
Gaia      bb36b4164d3e51ca04b612e507e1178f80bf240d
Gecko     4227240a4d3e1e418ced160c2a48cb454d7b5645
BuildID   20140204104742
Version   28.0