Last Comment Bug 729532 - Improve first-run profile import experience
: Improve first-run profile import experience
Status: VERIFIED FIXED
: late-l10n
Product: Firefox for Android
Classification: Client Software
Component: General (show other bugs)
: unspecified
: ARM Android
: P2 normal (vote)
: Firefox 14
Assigned To: Gian-Carlo Pascutto [:gcp]
:
Mentors:
Depends on:
Blocks: 739256
  Show dependency treegraph
 
Reported: 2012-02-22 07:43 PST by Madhava Enros [:madhava]
Modified: 2016-07-29 14:22 PDT (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed
beta+


Attachments
mockup of improved migration screen (569.81 KB, image/png)
2012-03-12 12:09 PDT, Ian Barlow (:ibarlow)
no flags Details
Patch 1. Rework setup screen. (5.44 KB, patch)
2012-03-20 09:42 PDT, Gian-Carlo Pascutto [:gcp]
mark.finkle: review+
akeybl: approval‑mozilla‑aurora+
Details | Diff | Splinter Review
Patch 2: Add the curved tab shape (5.16 KB, patch)
2012-03-22 16:12 PDT, Sriram Ramasubramanian [:sriram]
mark.finkle: review+
gpascutto: feedback-
Details | Diff | Splinter Review
Patch 3. Rename changed strings (3.93 KB, patch)
2012-03-26 09:57 PDT, Gian-Carlo Pascutto [:gcp]
mark.finkle: review+
akeybl: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Madhava Enros [:madhava] 2012-02-22 07:43:29 PST
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] 2012-02-22 07:50:01 PST
- 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 [:kbrosnan] 2012-03-01 10:55:01 PST
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] 2012-03-09 10:57:00 PST
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] 2012-03-10 01:06:55 PST
No, this needs a proposal (urgently, the string freeze is coming up!), taking into account the first 2 comments.
Comment 5 Madhava Enros [:madhava] 2012-03-12 09:49:36 PDT
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] 2012-03-12 09:51:08 PDT
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) 2012-03-12 12:09:23 PDT
Created attachment 605044 [details]
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] 2012-03-12 15:45:45 PDT
- 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?) 2012-03-12 15:49:58 PDT
(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] 2012-03-12 16:02:28 PDT
>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) 2012-03-13 06:29:29 PDT
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] 2012-03-14 13:19:25 PDT
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] 2012-03-20 09:42:49 PDT
Created attachment 607591 [details] [diff] [review]
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] 2012-03-22 16:12:54 PDT
Created attachment 608521 [details] [diff] [review]
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] 2012-03-26 08:31:49 PDT
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] 2012-03-26 08:43:20 PDT
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] 2012-03-26 09:57:13 PDT
Created attachment 609358 [details] [diff] [review]
Patch 3. Rename changed strings
Comment 18 Gian-Carlo Pascutto [:gcp] 2012-03-26 10:38:24 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/b09afc8b6b61
Comment 20 Gian-Carlo Pascutto [:gcp] 2012-03-27 08:11:00 PDT
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] 2012-03-27 08:11:25 PDT
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] 2012-03-28 14:44:01 PDT
Comment on attachment 607591 [details] [diff] [review]
Patch 1. Rework setup screen.

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

Note You need to log in before you can comment on or make changes to this bug.