1202422 - [New-Homescreen] Migrate app/bookmark order from verticalhome

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

Description

[Chris Lord [:cwiiis]]

We need to migrate app order from verticalhome to homescreen. This will require changes on both sides.

Comment 1

[Chris Lord [:cwiiis]]

So I've begun to tackle and think about this, but there are some issues that I think we need to address before taking this on;

For migration to work, verticalhome will have to be installed - this raises some complications as to how we want things to work from a UX perspective. I'll detail a few options:

1- We cut verticalhome down to a shell application that will just load its indexeddb, save it to a datastore and start the new homescreen (which will migrate those settings from the datastore). We hide verticalhome in the Settings app so the user can't accidentally switch back to it. I think this is probably one of the best plans in terms of UX. From a user perspective, the first launch will take a bit longer, but the penalty will only be paid once and data will be migrated. The downside of this approach is that it's a bit all-or-nothing with respect to switching over - verticalhome will be unavailable.

2- We keep both homescreens available and have verticalhome prompt to switch the user to the new homescreen. We can use a Ok/Cancel with a 'never ask me again' checkbox, or something along those lines. If the user picks Ok, we save the settings out to a datastore and switch the homescreen over (which probably requires extra permissions, but verticalhome is already certified at least). If the user switches the homescreen over to the new homescreen manually in the settings dialog, the settings won't be migrated (but perhaps this is expected behaviour? Android has similar issues with 3rd party launchers).

3- verticalhome always syncs its apps to a datastore every time it changes. This will slow down certain things, but probably not significantly(?) We can still prompt the user to switch if we want, but if they switch in the Settings menu, the app order will still migrate. We can flip a flag in verticalhome settings to get it to stop syncing at that point and restore its performance, if the user decides to switch back.

4- We only ship new homescreen, we don't migrate app order. We still get the default app-order (bug 1202423). Perhaps we can include some literature during the update to explain/apologise why app order hasn't been kept. The benefit is we don't have to modify or ship verticalhome, which save us some space and time and get a faster first-start.


I'm partial to either 1 or 4. 1 is nice because if the user wasn't using collections or collapsed groups, they would see very little difference when upgrading.

4 is nice because it makes the switch-over more explicit - the default app order is restored and the visuals are subtly, but noticeably different vs. verticalhome. It might be annoying to some, but it prompts an exploration of the new homescreen, which might help a user acclimatise and not feel too irritated when certain things work differently (I'm thinking of vertical paging especially).


I'd like to hand this over to UX to make a decision. I'm going to continue working on getting verticalhome to sync app order to a datastore, as there's a good chance we'll need this and I don't have other critical bugs to work on.

Comment 2

[Chris Lord [:cwiiis]]

To clarify for (1), we can separate it out into a combination of (3) and (1) - where verticalhome always syncs to a database but remains available, then we do (1) later and force the switch+make verticalhome unavailable.

Comment 3

[GitHub Autolander Bot]

Attachment: [gaia] Cwiiis:bug1202422-homescreen-migration > mozilla-b2g:master

Comment 4

[Chris Lord [:cwiiis]]

I spoke to Andrea about datastore, my worries about performance are likely unfounded, so it's not too big a deal for verticalhome to always store its settings in the datastore so that other homescreens can migrate from it whenever they choose (and not just new home).

That's what I've implemented so far, I'm just about to start the import in new homescreen. We can probably split out the decision of what to do with verticalhome post-switch to a different bug, but leaving the needinfo here so UX can start thinking about it (and let engineering know so we can start preparing).

Comment 5

[Chris Lord [:cwiiis]]

Import now working, just need to fix up some unit tests (probably) and write some unit tests and possibly an integration test.

Comment 6

[Chris Lord [:cwiiis]]

Comment on attachment 8664264 [details] [review]
[gaia] Cwiiis:bug1202422-homescreen-migration > mozilla-b2g:master

r?kgrandon for the changes to verticalhome and r?albertopq for the changes to new-homescreen.

This changes verticalhome to synchronise its items indexeddb to a datastore, and changes the first-run handler in new-homescreen to import it if it's there (and if it's not, it falls back to the default settings).

Comment 7

[Rob MacDonald [:robmac]]

(In reply to Chris Lord [:cwiiis] from comment #1)

Sorry for the delay as I've been in a workshop. I'll review this tomorrow and, in the meantime, will flag Wilfred for his thoughts as well.

- Rob

Comment 8

[Alberto Pastor [:albertopq]]

Just made a comment in GH. At the other hand, do you think we can add a UI test? Thanks!

Comment 9

[Chris Lord [:cwiiis]]

(In reply to Alberto Pastor [:albertopq] from comment #8)
> Just made a comment in GH. At the other hand, do you think we can add a UI
> test? Thanks!

Answered - I'll see if I can write a marionette test too.

Comment 10

[Alberto Pastor [:albertopq]]

Comment on attachment 8664264 [details] [review]
[gaia] Cwiiis:bug1202422-homescreen-migration > mozilla-b2g:master

r=me with a UI test, if possible

Comment 11

[Chris Lord [:cwiiis]]

Whoops, wrong bug :s

Comment 12

[Chris Lord [:cwiiis]]

(In reply to Alberto Pastor [:albertopq] from comment #10)
> Comment on attachment 8664264 [details] [review]
> [gaia] Cwiiis:bug1202422-homescreen-migration > mozilla-b2g:master
> 
> r=me with a UI test, if possible

comment addressed, integration test added.

Comment 13

[Kevin Grandon :kgrandon]

(In reply to Chris Lord [:cwiiis] from comment #1)
> 1- We cut verticalhome down to a shell application that will just load its
> indexeddb, save it to a datastore and start the new homescreen (which will
> migrate those settings from the datastore). We hide verticalhome in the
> Settings app so the user can't accidentally switch back to it. I think this
> is probably one of the best plans in terms of UX. From a user perspective,
> the first launch will take a bit longer, but the penalty will only be paid
> once and data will be migrated. The downside of this approach is that it's a
> bit all-or-nothing with respect to switching over - verticalhome will be
> unavailable.

I wouldn't spend the time doing this. I would just change the manifest role of verticalhome to be system, then you could still migrate from it.

Comment 14

[Kevin Grandon :kgrandon]

Comment on attachment 8664264 [details] [review]
[gaia] Cwiiis:bug1202422-homescreen-migration > mozilla-b2g:master

I don't think you should have code that runs always in verticalhome, until the default is switched. You probably want to trigger this from an IAC connection from either FTU (runs on upgrade) or the system app.

Comment 15

[Chris Lord [:cwiiis]]

(In reply to Kevin Grandon :kgrandon from comment #14)
> Comment on attachment 8664264 [details] [review]
> [gaia] Cwiiis:bug1202422-homescreen-migration > mozilla-b2g:master
> 
> I don't think you should have code that runs always in verticalhome, until
> the default is switched. You probably want to trigger this from an IAC
> connection from either FTU (runs on upgrade) or the system app.

This is a good idea, I hadn't thought of that...

What do you mean about changing the manifest role of verticalhome though, what would that do?

Comment 16

[Kevin Grandon :kgrandon]

(In reply to Chris Lord [:cwiiis] from comment #15)
> What do you mean about changing the manifest role of verticalhome though,
> what would that do?

That would allow the code to live in the tree still (with migration scripts), and allow you to message to it from FTU. It would be hidden from the list in the settings app.

Comment 17

[Rob MacDonald [:robmac]]

(In reply to Chris Lord [:cwiiis] from comment #1)
> So I've begun to tackle and think about this, but there are some issues that
> I think we need to address before taking this on;
> 
> For migration to work, verticalhome will have to be installed - this raises
> some complications as to how we want things to work from a UX perspective.

Hi Chris...

This is actually a difficult question to answer without understanding what we're trying to achieve with the new home page migration. If the goal is for foxfooders to try out the new home screen, we can probably ship both homescreens concurrently. If we're targeting end consumers, we should only ship one home screen and make the migration as seamless as possible. I've booked a call with Wilfred on Monday to get a product perspective.

- Rob

Comment 18

[Chris Lord [:cwiiis]]

Comment on attachment 8664264 [details] [review]
[gaia] Cwiiis:bug1202422-homescreen-migration > mozilla-b2g:master

I've reworked things so the migration is now activated by IAC. This adds some latency to switching away from verticalhome via settings, which I think we can address in follow-up. (I think part of this may be a bug where existing windows aren't reused for IAC? bug 818000)

I first tried doing this as a separate html and JS file, but that file had to pull in so much and work around so much inter-dependency that I didn't think it'd be worth the gain (I think a solution doing that would be either very delicate or involve a lot of code duplication - which would probably be delicate too, for different reasons).

Comment 19

[Chris Lord [:cwiiis]]

A separate point actually, maybe this migration should *only* be done by the OTA process, and not triggered via Settings, but I expect foxfooders may want it to work like this... I have no strong feelings here though.

Comment 20

[Kevin Grandon :kgrandon]

Comment on attachment 8664264 [details] [review]
[gaia] Cwiiis:bug1202422-homescreen-migration > mozilla-b2g:master

I think the verticalhome changes make sense, but I'm not sure if it makes sense to do this from the settings app. It feels like this code belongs in FTU or the system, and we should be able to just upgrade dogfooders if that's the plan. We should have a settings peer take a look at this code regardless, so flagging Fred to look at this.

Fred - could you take a look at this design and please review when you get a chance? Thanks!

Comment 21

[[e-mail]]

Comment on attachment 8664264 [details] [review]
[gaia] Cwiiis:bug1202422-homescreen-migration > mozilla-b2g:master

Instead of settings app, The right place to do global effected mozSettings key migration is in apps/system/js/migrators/settings_migrator.js

The migrator will detect whenever device is restarted (include FTU and noFTU situation)

Comment 22

[Chris Lord [:cwiiis]]

Comment on attachment 8664264 [details] [review]
[gaia] Cwiiis:bug1202422-homescreen-migration > mozilla-b2g:master

Flagging Etienne for review of the system bits.

Kevin, what do you think of this approach? Now, on upgrade, the verticalhome settings are checked, and if migration hasn't already been performed, it uses IAC to request verticalhome to export its data and switch homescreen.

I initially did this after checking the current homescreen, but we haven't officially had replaceable homescreens before 2.5, so I think we're ok to just do this unconditionally.

Comment 23

[Etienne Segonzac (:etienne)]

Comment on attachment 8664264 [details] [review]
[gaia] Cwiiis:bug1202422-homescreen-migration > mozilla-b2g:master

Hehe, so 

*r=me on the AppWindowManager change with the Service.query comment addressed
* the FtuLauncher change shouldn't be needed after that
* flagging Dale for the migrator change

Sorry for the review scattering but I know nothing about migrators :)

Comment 24

[Kevin Grandon :kgrandon]

Comment on attachment 8664264 [details] [review]
[gaia] Cwiiis:bug1202422-homescreen-migration > mozilla-b2g:master

I think something like this is probably fine. We should also probably remove BrowserMigrator, but that's another bug.

Comment 25

[Dale Harvey (:daleharvey)]

Comment on attachment 8664264 [details] [review]
[gaia] Cwiiis:bug1202422-homescreen-migration > mozilla-b2g:master

Yup the migrator looks sensible here, nice work

Comment 26

[Chris Lord [:cwiiis]]

I'll hold off on landing this until new-homescreen is the default, it doesn't make sense to migrate to a non-default homescreen.

Comment 27

[Wilfred Mathanaraj [:WDM]]

i assume we are moving this forward for 2.5 and planning ahead for post 2.5 release as part of the pin the web activities?

Comment 28

[Chris Lord [:cwiiis]]

(In reply to Wilfred Mathanaraj [:WDM] from comment #27)
> i assume we are moving this forward for 2.5 and planning ahead for post 2.5
> release as part of the pin the web activities?

Wilfred, could you clarify what you mean here? (sorry, I'm having difficulty understanding)

Comment 29

[Wilfred Mathanaraj [:WDM]]

did we do this for 2.5?

Comment 30

[Chris Lord [:cwiiis]]

(In reply to Wilfred Mathanaraj [:WDM] from comment #29)
> did we do this for 2.5?

I'm still not really sure what's being asked... We intend to ship new-homescreen with 2.5 (right?), this bug is to do with migrating settings from verticalhome to the new homescreen.

There were questions on how exactly this should happen, but I think we have a good enough path here now.

Comment 31

[Chris Lord [:cwiiis]]

Merged: https://github.com/mozilla-b2g/gaia/commit/9257f9cc2723064ef18e4c4d339c75f35a97763b

Again, fingers crossed...

Comment 32

[Nigel Babu [:nigelb]]

I've backed out bug 1202422 and bug 1191745 on causing the fairly disastrous Gij17 bustage. Could you please look into it?

Comment 33

[Chris Lord [:cwiiis]]

Re-landed: https://github.com/mozilla-b2g/gaia/commit/497143e60a6eb1f4c266b84d244a788cd1a93806