832898 - [FTU] Implement FB Import as per the latest UX specifications

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::First Time Experience, defect)

Description

[Jose Manuel Cantera]

Attachment: Visual Design Part I

See attached Visual Designs

Comment 1

[Sergi]

Attachment: Visual Design Part I

Comment 2

[Maria Angeles Oteo (:oteo)]

Not blocking, but please, set the tracking-b2g18+ so we can have the same behavior with import SIM/FB in FTU and Contact settings. 
It's very important to show the same behavior in both app as UX has pointed out

Comment 3

[Jose Manuel Cantera]

Attachment: Pointer to GH PR #7757

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This doesn't seem like something we can do until v1.1

Comment 5

[Maria Angeles Oteo (:oteo)]

(In reply to Jonas Sicking (:sicking) from comment #4)
> This doesn't seem like something we can do until v1.1

I don't undrestand you, what does it mean tracking-b2g18: + → 20+  ?
the patch is ready and it's necessary to have the same screen and behaviour in FTU and Contact settings for importing, otherwise it's incoherent.

Comment 6

[Staś Małolepszy :stas]

Comment on attachment 705371 [details]
Pointer to GH PR #7757

Can you please add the English string to the HTML for consistency's sake?

Also, it looks like the 'notImportedYet' string isn't used anymore at all.  Please file a new bug so that we remember to remove it after all the master/1.0.0/1.0.1 has been figured out.

With that, r=me.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Even though a patch is ready, there is always a risk of regressions associated with landing it. At this point in the release cycle we really have to restrict ourselves to only critically important patches.

If you think this is one of them, feel free to renominate.

Comment 8

[Fernando Campo (:fcampo)]

Comment on attachment 705371 [details]
Pointer to GH PR #7757

All well, thank you for the style changes too :)

Comment 9

[Jose Manuel Cantera]

landed in master branch

https://github.com/mozilla-b2g/gaia/commit/bdbafdbf0d2e8f5b0f090c0664d5b93bd9026416

Comment 10

[Maria Angeles Oteo (:oteo)]

We know this is not blocking but we need it as tracking-b2g18+ for the sake of consistency.
I don't know yet why Jonas set it to 20+ if it was triaged as tracking-b2g18+ and thepatch is ready, it's safe and is necessary.

Please, set it as tracking-b2g18+

Comment 11

[Rafael Rebolleda]

Hey guys, 

I think it's really important to land this patch from UX POV. It's not only about consistency with Contacts, which is important, but it's about an improved flow with better expectations and fewer loopholes.

A very low risk change for a simpler, faster and smoother ride. We should definitely bring this to TEF's release.

Comment 12

[Rafael Rebolleda]

Guys, 

I'm bumping this thing up to P1. The more I see it the more it annoys me. We already have a patch landed and this is a very low risk enhancement, and there no reason not prevent users from enjoying a nicer, more consistent experience.

Comment 13

[Jose Manuel Cantera]

Comment on attachment 705371 [details]
Pointer to GH PR #7757

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Alignment between FTU and Contact Settings
User impact if declined: High from a quality perception perspective as the FTU is the first app the user interacts with a device
Testing completed: Yes, thorough review by 3 different people
Risk to taking this patch (and alternatives if risky): Low

Comment 14

[Jose Manuel Cantera]

As Rafa pointed out there is no reason for not landing the patch in the train. You can see two different screen captures on which you can feel the difference between the consistent and not consistent design and experience.

Comment 15

[Jose Manuel Cantera]

Attachment: Correct implementation

Comment 16

[Jose Manuel Cantera]

Attachment: Current (incorrect) implementation

you can see that there is no consistency in the used visual elements and interaction

Comment 17

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Jose M. Cantera from comment #14)
> As Rafa pointed out there is no reason for not landing the patch in the
> train. You can see two different screen captures on which you can feel the
> difference between the consistent and not consistent design and experience.

There are reasons, mentioned in comment 7, that we could have risks of regressions we don't want at such a late landing.  In the real world this screen is only showed to the user one time - the need for consistency is polish and not a blocker to shipping. We'll hold this for v1.1 approval.

Comment 18

[Maria Angeles Oteo (:oteo)]

(In reply to Lukas Blakk [:lsblakk] from comment #17)

> There are reasons, mentioned in comment 7, that we could have risks of
> regressions we don't want at such a late landing. 

After 20 days landed in master we have some guarantees that there are not regression :)
Tested by me in master and working pefectly

In the real world this
> screen is only showed to the user one time - the need for consistency is
> polish and not a blocker to shipping. We'll hold this for v1.1 approval.

not blocking the functionality but from UX point view, who are the expert on these issues, it's an important inconsistency bug (see comment #12) and the FTU is the first impression a user has of the device, so we need to be careful about it.

Comment 19

[Alex Keybl [:akeybl]]

(In reply to Jonas Sicking (:sicking) from comment #7)
> Even though a patch is ready, there is always a risk of regressions
> associated with landing it. At this point in the release cycle we really
> have to restrict ourselves to only critically important patches.
> 
> If you think this is one of them, feel free to renominate.

This is not a blocker, or a critical UX bug as agreed to 2 weeks ago, therefore a new conversation would need to happen to take this for v1.0.1. Approving for v1.1.

Comment 20

[John Ford [:jhford] CET/CEST Berlin Time]

This commit does not apply cleanly to v1-train.  If this patch depends on another bug, please comment here and I will retry when that bug is approved to land on all branches that this bug needs to land on.  If the merge conflict needs to be resolved by hand, the following commands could be a useful starting point:

cd gaia
git checkout v1-train
git cherry-pick -x -m1 bdbafdbf0d2e8f5b0f090c0664d5b93bd9026416
<resolve merge conflict>

#	both modified:      apps/communications/ftu/css/style.css
#	both modified:      apps/communications/ftu/js/navigation.js
#	both modified:      apps/communications/ftu/js/sim_manager.js

Comment 21

[Jose Manuel Cantera]

landed in v1-train as requested

https://github.com/mozilla-b2g/gaia/commit/45f49ae6a770537f04832086365cb517e0a41840