1036697 - Separate FTE and Tutorial into different apps

Status: RESOLVED WONTFIX

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

Description

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Around the system app, we make a ton of assumptions that the FTE running means that it's the first boot of the phone ever. This changes our normal boot flow by doing things like turning off the SIM PIN dialog. However, as of v2.0, we now need the tutorial to come up on upgrade, which means we bring up the FTE in non-first-time-use situations. This is the root cause of bugs like Bug 1031369. 

We should divide the tutorial into its own app that can be launched via either the system app or the FTE, so we no longer run into system conflicts like this. 

I would figure this is 2.1 scope at the earliest.

Comment 1

[Sam Foster [:sfoster] (he/him)]

Agreed in principle. Note that we have a separate effort to make the tutorial more of a in-context tour. That would probably also benefit from being a separate app, and I think usability-wise its important to be able to re-play the tutorial at any time without side-effects.

Comment 2

[Kai-Chih Hu [:khu]]

Use feature-b2g:2.2? rather than just 2.2.

Comment 3

[Candice Serran (:cserran)]

2.2 Feature scope has been locked down --will be placed in backlog.

Comment 5

[Sam Foster [:sfoster] (he/him)]

Have a patch in progress for this, will attach PR when its a bit more stable.

Comment 6

[GitHub Autolander Bot]

Attachment: [gaia] sfoster:ftu-tour > mozilla-b2g:master

Comment 7

[Sam Foster [:sfoster] (he/him)]

Comment on attachment 8700973 [details] [review]
[gaia] sfoster:ftu-tour > mozilla-b2g:master

Patch is still a work in progress, but its there in broad strokes. Enough to make a go/no-go call I guess? I stopped short of optimizing the startup path in the system Launcher & FtuLauncher, and elected to leave the logic pretty much as-is for this patch; we can build on this to tweak that stuff as necessary later. 

Known todos: 

* I need to resolve the ambiguity in the finish screen for FTU and start screen for Tour. As the FTU doesnt know if there are any tutorial steps to show, we can end up showing a "join us for quick tour" screen in FTU, followed by a "That's it!" screen in tour as there's no steps to show. 

* Possibly look at Tour startup to not raise the curtain until the first video is loaded. 

* Update unit tests
* Update marionette tests

* Will probably remove fullscreen flag and show statusbar in tour.

Comment 8

[Sam Foster [:sfoster] (he/him)]

Comment on attachment 8700973 [details] [review]
[gaia] sfoster:ftu-tour > mozilla-b2g:master

Cancelling f? for now as I've got a new version of this patch in the works. It turns out that some startup path/launcher refactoring does need to happen to make this work. Something like:

* Launcher: when isUpgrading, call service.request('FtuLauncher:launchUpdateTour') 
* FtuLauncher launchUpdateTour does skip(), and launches the tour app (we'll get manifestURL from settings like we do for FTU)
* Tour app will need params to know which steps in which tour to play. We can get these from the URL, from the activity message, or from mozSettings. If we launch the Tour app using its DOMApp.launch(), we don't get to pass any params or other context. Using mozSetttings means have to be careful to not update the deviceinfo.previous_os value until the Tour app has read them (and needs permissions to read them - also not ideal) Launching Tour from FtuLauncher as an activity lets us pass this info, and mirrors how in the current patch we launch the Tour in the FTU, so I'll probably go this route. 

Using an activity seems a bit weird, as it wouldn't make sense to pick a different app to provide the tour functionality. But in the current gaia model, it seems the best way to make it happen.

Comment 9

[Sam Foster [:sfoster] (he/him)]

While b2g may live on, FTU will not.