729532 - Improve first-run profile import experience

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect, P2)

Description

[Madhava Enros [:madhava]]

Opening as a followup to bug 710331. My last comment there was:

Let's open a new bug for UX improvements here. I think we need to find a compromise between:

- reducing the overall time required
- making the time we can't cut less visible (i.e. on demand; hidden while something else is happening; other)
- where we can't hide it, distracting the user more (i.e. progress, or having some other conversation with them)
- making it clear that this is a one time thing

Just providing more detail isn't necessarily going to make for a better experience.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

- hidden while something else is happening

This is what we originally had - the problem is that the I/O impact of the import is so big that it slows down most phones to a crawl. That's why we went with a blocking screen.

We have some ideas how to get the time down, but there are users with 1000, 2000, ... bookmarks out there. Even if we get them implemented, it might still take a while.

There is also no indication that this is a one-time thing, and it looks similar to the screen that old users got on every Fennec start.

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

Which of the items listed in comment 1 are highest priority. Getting UI and strings squared away for the aurora merge would be best.

Comment 3

[JP Rosevear [:jpr]]

Madhava, gcp, do we have agreement here on how to move forward here since this is a beta blocker?

Comment 4

[Gian-Carlo Pascutto [:gcp]]

No, this needs a proposal (urgently, the string freeze is coming up!), taking into account the first 2 comments.

Comment 5

[Madhava Enros [:madhava]]

How do you characterize the time it's taking now? We were hoping for some numbers/ranges about typical waits, and what it would look like at extremes as well.

The text should indicate that it's a one-time thing: "Setting up Firefox", but, depending on how long this is going to take, we might want some more subdivision.

Assigning to to ibarlow for futher thoughts.

Comment 6

[Madhava Enros [:madhava]]

Also - to be clear - this affects the set of people who:

- have already been using Firefox
- have a big profile, possibly because of Sync

Which might affect whether we thinks this should block.

Comment 7

[Ian Barlow (:ibarlow)]

Attachment: mockup of improved migration screen

Hi all, attached is an updated mockup for our migration UI. I've included a little more explanation to users what is going on, and tweaked the design so it doesn't look like the same old dark grey startup screen so many people have grown to know and hate. 

I was talking to GCP in IRC and he has also improved migration speed by quite a lot, so the description of taking "a minute or so" should be accurate in *most* cases.

Further enhancements to this UI *could* include:
- Detecting how many items need to be imported in total, and displaying some kind of progress indicator to the user. GCP is looking into the feasibility of this, and the potential performance cost, if any.

Comment 8

[Gian-Carlo Pascutto [:gcp]]

- There's no penalty for adding an xxx out of yyy performance indicator, outside the cost of doing the graphical update.

- There are two phases: history import and bookmarks import. We don't know how long bookmarks will take when we start history. (This means a single progress bar is tricky, unless we fill it twice)

- We're still discussing in bug 721898 whether to truncate history, and to how much. Right now we limit to 250 entries. The decision there directly affects the migration time.

I did some testing: on a Galaxy Tab 10.1, I'm able to import 5000 history entries and 200 bookmarks in 80 seconds. I think this means that most users will have sub-minute migration times now. Unless we really do import all their history (129000 items in my own profile).

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Gian-Carlo Pascutto (:gcp) from comment #8)
> - There are two phases: history import and bookmarks import. We don't know
> how long bookmarks will take when we start history. (This means a single
> progress bar is tricky, unless we fill it twice)
Can we query the number of bookmarks before starting the history import?

Comment 10

[Gian-Carlo Pascutto [:gcp]]

>Can we query the number of bookmarks before starting the history import

We can do an extra COUNT(*) query. It won't be free, but it should be fast (<1s).

What really happens is all of the following:

- fetch all Android/LocalDB history
- fetch all XUL history
- construct an array of all database ops
- commit this to disk (one very big operation)
- post a runnable to send it through to Gecko
- fetch all XUL bookmarks
- for every bookmarks folder:
 - construct an array of all database ops
 - commit this to disk

We can't update the display during the fetch and commit phases. If we display a progress bar it will end up being a bit "choppy", and will run at unequal speeds during the progress.

Comment 11

[Ian Barlow (:ibarlow)]

Let's get this page implemented as per the mockup first, and if we have time let's see how the progress indicator feels. If it ends up being very choppy as you say, it may be preferable to leave it out...

Comment 12

[Gian-Carlo Pascutto [:gcp]]

I did some more testing on a Samsung Galaxy S2, internal/sdcard storage, Android 2.3.6. This is probably middle-to-high-end as far as speed is concerned. Newer Androids will be faster due to newer SQLite. Older ones and ones with bad filesystems may be slower.

https://docs.google.com/spreadsheet/ccc?key=0AiObroK0ZHF-dGY2UDdaNDRaLWs4Ykt5MDFTS0tJb2c

From this, we can derive the approximation:

time = 14 + bookmarks/58 + history/86

For example, this predicts 76s for the situation in comment 8, where 80s was observed. Bookmarks is a bit slower than history because there's a FOREIGN KEY constraint, and they are a tree structure that takes a bit more work to insert in the right order.

During this operation, my device was fairly usable, but it's a dual-core one. I'm not so sure it's going to be as pleasant on a Nexus S for example.

If we assume a normal user has at most 500 bookmarks, and we want to spend about a minute on migrating his stuff, we should put the cut off for history around 3000 entries.

On my own profile, this would give us history back to Wed, 25 May 2011 16:48:20 GMT, or about 3 weeks of surfing.

Comment 13

[Gian-Carlo Pascutto [:gcp]]

Attachment: Patch 1. Rework setup screen.

Despite quite some effort, I kept running into a problem with the Awesomebar (or the mockup thereof) having its top cut off: https://twitter.com/#!/gcpascutto/status/182142470790979584/photo/1

blassey also had a quick look, but even the most basic layout that includes of BrowserToolbar fails in the same way. 

It can be worked around by adding some arbitrary top padding, but that's not very satisfying.

Given that this contains string changes, let's land the part we have and not get hung up over this (...any more than I already was). If someone figures out what I'm missing, feel free to post a followup patch with polish.

Comment 14

[Sriram Ramasubramanian [:sriram]]

Attachment: Patch 2: Add the curved tab shape

This adds the curved tab shape. This should be applied on top of Patch #1.

Comment 15

[Gian-Carlo Pascutto [:gcp]]

Comment on attachment 608521 [details] [diff] [review]
Patch 2: Add the curved tab shape

On my Galaxy S2 2.3.6, this has exactly the same problem as my original patch above. The tab button is halfway off the screen.

Comment 16

[Gian-Carlo Pascutto [:gcp]]

Only pushed the first part:

https://hg.mozilla.org/integration/mozilla-inbound/rev/2722ebdf066f

Will make a follow-up bug for getting the "tab shape" right.

Comment 17

[Gian-Carlo Pascutto [:gcp]]

Attachment: Patch 3. Rename changed strings

Comment 18

[Gian-Carlo Pascutto [:gcp]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b09afc8b6b61

Comment 19

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/2722ebdf066f
https://hg.mozilla.org/mozilla-central/rev/b09afc8b6b61

Comment 20

[Gian-Carlo Pascutto [:gcp]]

Comment on attachment 607591 [details] [diff] [review]
Patch 1. Rework setup screen.

[Approval Request Comment]
Improved UX for first start.

Comment 21

[Gian-Carlo Pascutto [:gcp]]

Comment on attachment 609358 [details] [diff] [review]
Patch 3. Rename changed strings

[Approval Request Comment]
Improved UX for first run. Mostly string/layout changes.

Comment 22

[Alex Keybl [:akeybl]]

Comment on attachment 607591 [details] [diff] [review]
Patch 1. Rework setup screen.

[Triage Comment]
Mobile only - approved for Aurora 13.

Comment 23

[Gian-Carlo Pascutto [:gcp]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/782c225589ef
https://hg.mozilla.org/releases/mozilla-aurora/rev/932c7d9b6fc3