Upon very first power up (after factory reset), the user should be provided an option to select the SIM(s). The flow should also include unlocking the SIM with a SIMPIN1.

Peter, is it something in system front-end team? Thanks!

(In reply to Kevin Hu [:khu] from comment #1) > Peter, is it something in system front-end team? Thanks! I'm not sure that the Systems FE team has capacity to do this in 1.3.

Who can we ask for help?

Acceptance criteria from PM: 1) At the first power up (after factory reset), the user should be provided an option to select the SIM(s) with a way to enable/disable standby for each SIM. Default will be both SIMs enabled for standby. 2) The flow should also include unlocking the SIM(s) with a SIMPIN1 in case the SIM(s) is locked. 3) In order for limiting the scope of FTE, a simple screen indicative of SIM selection is acceptbale for 1.3 timeframe. We can elabprate more on the integrated FTE experience in 1.4 timeframe.

Hi Sandip, Based on UX spec, SIM manager in FTE will only display SIM information, no other functions user can interact with, which means that acceptance criterion 1 will not be fulfilled. Please let us know if you have any concern for changing criteria as follow. I am not sure this is the same meaning as your no.3 criterion. Update acceptance criteria: 1) At the first power up (after factory reset), user can see a SIM manager page in FTE flow with SIM card information and default will be both SIMs enabled for standby. 2) The flow should also include unlocking the SIM(s) with a SIMPIN1 in case the SIM(s) is locked. 3) In order for limiting the scope of FTE, a simple screen indicative of SIM selection is acceptbale for 1.3 timeframe. We can elabprate more on the integrated FTE experience in 1.4 timeframe.

Joe, can you help to find someone from FTE team to work on this bug? Thanks.

update moztrap link for this user story.

this user story is outside of 1.3 scope in 1.3, an information page is provided without being able to select a SIM this should be under System FE team. ni? gregor / candice

(In reply to Enpei from comment #5) > Hi Sandip, > > Based on UX spec, SIM manager in FTE will only display SIM information, no > other functions user can interact with, which means that acceptance > criterion 1 will not be fulfilled. Please let us know if you have any > concern for changing criteria as follow. I am not sure this is the same > meaning as your no.3 criterion. > > Update acceptance criteria: > 1) At the first power up (after factory reset), user can see a SIM manager > page in FTE flow with SIM card information and default will be both SIMs > enabled for standby. > > 2) The flow should also include unlocking the SIM(s) with a SIMPIN1 in case > the SIM(s) is locked. > > 3) In order for limiting the scope of FTE, a simple screen indicative of SIM > selection is acceptbale for 1.3 timeframe. We can elabprate more on the > integrated FTE experience in 1.4 timeframe. That is what I meant by #3 actually, so I am okay with this scope for v1.3.

Per comment 9. change the description of the bug Filed Bug 937424 - [B2G][User Story] [DSDS] Selection of the SIMs during FTE so the original scope of this bug can be tracked in v1.4 and beyond

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

(In reply to Kevin Hu [:khu] from comment #11) > Remove blocking-b2g flag from User Story bugs. Use whiteboard to indicate > what FxOS version we target. Well all the queries we are using are filtered by the blocking flag. I don't think using the whiteboard is a good idea here.

It looks like different functional teams are using different query criteria. I am fine either way as long as we have some aligned rules. I remember that Dietrich does not think it's a good idea to mark blocking-b2g flag on user story bugs? Dietrich, if it's not the case, I am sorry for my bad memory. Gregor, what queries that you're using now? Thanks!

sent email re blocker flags on feature bugs. Gregor: the whiteboard flags are what the PM team uses to track user stories, and will be there whether you use blocking flags or not. https://wiki.mozilla.org/FirefoxOS/ProgramManagement#Bugzilla_Flags

Hi Jason, I've written some draft test case and updated moztrap link in URL. Just to make sure there is no duplicate job here. Feel free to discuss the test cases off line with me.

(In reply to Enpei from comment #15) > Hi Jason, > > I've written some draft test case and updated moztrap link in URL. Just to > make sure there is no duplicate job here. Feel free to discuss the test > cases off line with me. Oh - I missed that initially. Okay, I'll flag in-moztrap+ here then to indicate there's coverage here.

Candice, can you help to track this work in system front end team? Thank you!

Candice, can you help to track this user story? Engineering bugs? Thanks!

WIP

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

Comment on attachment 8339085 [details] PR, add 2 SIM unlock screens, SIM info screen Ok, I think this one is ready. Francisco, do you mind having a look?

Hi Sandip, I have a question about the user acceptance criteria for this bug. The spec and moztrap cases don't seem to mention the "Enable Cell Data" FTU step. However, in current builds we only show this screen if the SIM is present and unlocked. So perhaps we should update the moztraps cases to mention that this screen should only be shown when at least one SIM is present and unlocked?

(In reply to Michael Henretty [:mhenretty] from comment #22) > Hi Sandip, > > I have a question about the user acceptance criteria for this bug. The spec > and moztrap cases don't seem to mention the "Enable Cell Data" FTU step. > However, in current builds we only show this screen if the SIM is present > and unlocked. So perhaps we should update the moztraps cases to mention that > this screen should only be shown when at least one SIM is present and > unlocked? Hi Michael, in UX v0.8 spec, page 17, it did mention SIM manager will not be presented when there is only one SIM or no SIM. This has been covered in moztrap #10656 and #10657. And #10654, 10655 and 10662 will verify SIM PIN cases. I will attach UX spec from UX team later.

UX spec is attached in bug 938422.

Hi Enpei, Thank you for responding. I did see the spec mentioning the SIM manager. The page I am talking about when I say "Enable Cell Data" is the step in the FTU after the SIM Manager where the user chooses whether or not they want to enable their cell data connection. In the pre-DSDS FTU, this page would only be shown if there was a SIM present and unlocked, so the new behavior should be something similar even though it is not specifically specified in the v0.8 of the spec. I had to modify some code here to accommodate this, so it's probably good if we have some moztraps for it.

Right now there is an issue with the Fugu where we cannot accurately obtain the SIM unlock retry count. Until this is fixed, we can't meet the spec for the SIM unlock screens.

(In reply to Michael Henretty [:mhenretty] from comment #21) > Comment on attachment 8339085 [details] > PR, add 2 SIM unlock screens, SIM info screen > > Ok, I think this one is ready. Francisco, do you mind having a look? Note - this needs a UI review before landing.

Michael, could you attach screenshots of the patch for the UI review? I'm taking over FTE UX from Francis, so I will be reviewing this bug.

(In reply to Michael Henretty [:mhenretty] from comment #26) > Right now there is an issue with the Fugu where we cannot accurately obtain > the SIM unlock retry count. Until this is fixed, we can't meet the spec for > the SIM unlock screens. Hi Michael, I got your point now. Thanks for the reminding! I will add the verification steps in moztrap test cases for this user story.

Wrong reply in previous comment. (In reply to Michael Henretty [:mhenretty] from comment #25) > Hi Enpei, > > Thank you for responding. I did see the spec mentioning the SIM manager. The > page I am talking about when I say "Enable Cell Data" is the step in the FTU > after the SIM Manager where the user chooses whether or not they want to > enable their cell data connection. In the pre-DSDS FTU, this page would only > be shown if there was a SIM present and unlocked, so the new behavior should > be something similar even though it is not specifically specified in the > v0.8 of the spec. I had to modify some code here to accommodate this, so > it's probably good if we have some moztraps for it. Hi Michael, I got your point now. Thanks for the reminding! I will add the verification steps in moztrap test cases for this user story.

I've attached four screenshot: SIM unlocking screen, a failed pin entry, and 2 SIM Managers, each with 1 of the SIMs locked. They are in 320x480, which is believe matches the Fugu spec. Let me know if you need other resolutions, or anything else really.

Comment on attachment 8339085 [details] PR, add 2 SIM unlock screens, SIM info screen Just left some comments on github. Mainly two things: - Prefer this PR to be separated in two, one for the sim message, and another for the unlock. - Navigation is broken if we skip pin entry and we change mind and decide to go back and enter the pin again, we won't show again the pin entry screen. A part from that, requiring some info from Kevin Grandon, since the modification for the desktop shim always enables DSDS features, and perhaps that should be added via a pref during build time.

@Kevin, with this change we will show DSDS UI all the time in Desktop, what do you think about the changes in the desktop shim, should we control the DSDS functionality through a pref or extra parameters on build time?

(In reply to Francisco Jordano [:arcturus] from comment #33) > @Kevin, with this change we will show DSDS UI all the time in Desktop, what > do you think about the changes in the desktop shim, should we control the > DSDS functionality through a pref or extra parameters on build time? It doesn't really seem like a blocker to me TBH. Ideally we'd have a dropdown in the devtools which could toggle the number of sim slots, and even emulate sim insertion/removal. I don't see anything wrong with landing this now, and doing some polish in a follow-up patch.

Overall the screens are looking good, just a few things: Since these screens are part of the regular FTE flow for Dual Sim devices, it should incorporate the progress bar found at the top of the FTE screens. This informs the users about their progress through the FTE flow. As well, I believe in the DSDS specs, the SIM Pin entry screens had a back arrow that would allow the user to navigate back a step rather than skipping the pin. Also, visual should take a look at these screens, ni on Eric to review them.

Hi, I've taken a look at the screens. There seems to be some issues with the styling and layout. These screens should follow what is currently being used in the other FTE and setting screens. I've attached a couple of current/corrected screens. Let me know if details specs are needed. I've also added the progress bar in the screens that that Jacqueline previously mentioned. Thanks!

(In reply to Francisco Jordano [:arcturus] from comment #32) > - Prefer this PR to be separated in two, one for the sim message, and > another for the unlock. It is hard to separate this into two pull requests. The SIM manager relies on new information that gets set in the SIM unlock screen, so decoupling this would be tricky and require some code change. Also, if the reason is to be able to back out these features separately, I think it would be strange for the user to see a 2 SIM info screen without being able to unlock the second pin. > - Navigation is broken if we skip pin entry and we change mind and decide to > go back and enter the pin again, we won't show again the pin entry screen. Ah, good catch, will fix.

(In reply to Michael Henretty [:mhenretty] from comment #25) Hi Michael, I'm the DSDS UX owner. Sorry for missing the information of enabling cell data connection on FTE in the spec. I'm with you on this issue that we shall align the single-SIM behavior here. The page will only be shown when there is at least one SIM presented and also unlocked. Thanks! > Hi Enpei, > > Thank you for responding. I did see the spec mentioning the SIM manager. The > page I am talking about when I say "Enable Cell Data" is the step in the FTU > after the SIM Manager where the user chooses whether or not they want to > enable their cell data connection. In the pre-DSDS FTU, this page would only > be shown if there was a SIM present and unlocked, so the new behavior should > be something similar even though it is not specifically specified in the > v0.8 of the spec. I had to modify some code here to accommodate this, so > it's probably good if we have some moztraps for it.

(In reply to jsavory from comment #35) > Since these screens are part of the regular FTE flow for Dual Sim devices, > it should incorporate the progress bar found at the top of the FTE screens. > This informs the users about their progress through the FTE flow. It is problematic to add the progress bar here because the number of FTE steps changes depending on if the user unlocks a SIM or not (ie. we will not show the "Enable Cell Data" (different from SIM Manager) screen if both SIMs stay locked). So, the size of the progress element could change based on the user's actions here. I believe that is why the old SIM unlock screen did not contain a progress element, and behaved more like a pop-up. In any case, if we do decide to add the progress element here, would you mind if we filed a follow up bug and landed this in 1.4 since it was not a part of the original spec? > As well, I believe in the DSDS specs, the SIM Pin entry screens had a back > arrow that would allow the user to navigate back a step rather than skipping > the pin. Ah sorry good catch! Will fix.

Hi Eric, These latest images I pulled directly from the phone. I think the font issue we were seeing in the last attachment was because I pulled it from the simulator rather than the phone. Sorry about that! (In reply to Eric Pang [:epang] from comment #36) > Let me know if details specs are needed. In general, detailed specs are really helpful, especially since the previous spec was very detailed about alignment, font-colors, etc and a lot of those alignments changed in this review. I tried to eyeball it the best I could since we are under deadline, but yes please provide details when making such changes to the prev spec. Here is the prev spec I had, perhaps it was outdated? https://bug917705.bugzilla.mozilla.org/attachment.cgi?id=8342704 > I've also added the progress bar in the screens that that Jacqueline > previously mentioned. Thanks! I didn't add the progress bar yet. Please see comment 39 as to the status of this.

Comment on attachment 8339085 [details] PR, add 2 SIM unlock screens, SIM info screen Francisco, I believe I have addressed your concerns (except for splitting this into two PR's which I talk about above), and also fixed the "back" button issue you found. If I get the r+ from you, I will of course flatten and make sure travis is green before landing. Thanks!

For each section of FTE, any additional screens maintain the same location on the progress bar. For example, entering a wifi password presents a new page but the progress bar remains in the same place as the wifi selection screen. We could implement the same logic for the Dual Sim screens. Essentially, the SIM Manager page would be a new section on the progress bar and any additional screens would show the progress bar but would not advance its progress. However, I understand that this wasn't in the original specs and that we have a tight deadline. I am fine with filing a new bug for this for 1.4.

(In reply to jsavory from comment #42) > Essentially, the SIM Manager page would be a new section on the progress bar > and any additional screens would show the progress bar but would not advance > its progress. Makes sense. > However, I understand that this wasn't in the original specs and that we > have a tight deadline. I am fine with filing a new bug for this for 1.4. Great! I appreciate the flexibility, and I have filed the follow up here: https://bugzilla.mozilla.org/show_bug.cgi?id=949439

Comment on attachment 8339085 [details] PR, add 2 SIM unlock screens, SIM info screen r+ with some comments in github, not blocking on them. Please merge once travis is green (don't know why the jobs for this PR timed out, all of them). Great job! Thanks a lot, F.

Comment on attachment 8345932 [details] screenies2.zip These look great, thanks Michael!

koi+, please land the patch.

(In reply to Preeti Raghunath(:Preeti) from comment #46) > koi+, please land the patch. This has no relation to koi at all. It's a 1.3 blocker though.

Hey Michael, Since this has been r+, do we have an eta when this will land? Thanks in advance :)

(In reply to Candice Serran from comment #48) > Hey Michael, > > Since this has been r+, do we have an eta when this will land? Thanks in > advance :) Hi Candice, This is ready to land at any time, But Travis has been borked since last week (https://groups.google.com/forum/#!topic/mozilla.dev.gaia/byjzv__yqh8). I think that issue is fixed now, so as soon as I can get a green run I will land it.

master: https://github.com/mozilla-b2g/gaia/commit/e2c232208f0177d7a9305a60a6c59e62d98a67a2 This still needs to be uplifted to 1.3

This still needs to be uplifted to v1.3. Setting flag for it.

I was not able to uplift this bug to v1.3. If this bug has dependencies which are not marked in this bug, please comment on this bug. If this bug depends on patches that aren't approved for v1.3, we need to re-evaluate the approval. Otherwise, if this is just a merge conflict, you might be able to resolve it with: git checkout v1.3 git cherry-pick -x -m1 e2c232208f0177d7a9305a60a6c59e62d98a67a2 <RESOLVE MERGE CONFLICTS> git commit

Uplifted to v1.3: https://github.com/mozilla-b2g/gaia/commit/db663412548ed3686266e041a6240178d2ed9680

Verified on Fugu. All acceptance criteria are passed. Fugu Gaia 22bc6be5b76cdc6d4e9667ff070979041a20ce2f Gecko cd8bc54e911470fa6519d461e5e6b3ddc8f57f5f BuildID 20140109175226 Version 28.0a2