Improve first-run profile import experience

VERIFIED FIXED in Firefox 13

Status

()

Firefox for Android
General
P2
normal
VERIFIED FIXED
6 years ago
a year ago

People

(Reporter: madhava, Assigned: gcp)

Tracking

({late-l10n})

unspecified
Firefox 14
ARM
Android
late-l10n
Points:
---

Firefox Tracking Flags

(firefox13 fixed, blocking-fennec1.0 beta+)

Details

Attachments

(4 attachments)

(Reporter)

Description

6 years ago
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.
(Assignee)

Comment 1

6 years ago
- 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.

Updated

6 years ago
OS: Mac OS X → Android
Hardware: x86 → ARM

Updated

6 years ago
blocking-fennec1.0: --- → ?
Which of the items listed in comment 1 are highest priority. Getting UI and strings squared away for the aurora merge would be best.
Assignee: nobody → madhava

Updated

6 years ago
blocking-fennec1.0: ? → beta+

Comment 3

6 years ago
Madhava, gcp, do we have agreement here on how to move forward here since this is a beta blocker?
(Assignee)

Comment 4

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

Comment 5

6 years ago
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.
Assignee: madhava → ibarlow
(Reporter)

Comment 6

6 years ago
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.
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.
Priority: -- → P2
(Assignee)

Comment 8

6 years ago
- 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).
(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?
(Assignee)

Comment 10

6 years ago
>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.
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...

Updated

6 years ago
Assignee: ibarlow → gpascutto
(Assignee)

Comment 12

6 years ago
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.
(Assignee)

Comment 13

6 years ago
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.
Attachment #607591 - Flags: review?(mark.finkle)
Attachment #607591 - Flags: review?(mark.finkle) → review+
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.
Attachment #608521 - Flags: review?(mark.finkle)
Attachment #608521 - Flags: review?(mark.finkle) → review+
(Assignee)

Comment 15

6 years ago
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.
Attachment #608521 - Flags: feedback-
(Assignee)

Comment 16

6 years ago
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.
(Assignee)

Updated

6 years ago
Blocks: 739256
(Assignee)

Updated

6 years ago
Keywords: uiwanted
(Assignee)

Comment 17

6 years ago
Created attachment 609358 [details] [diff] [review]
Patch 3. Rename changed strings
Attachment #609358 - Flags: review?(mark.finkle)
Attachment #609358 - Flags: review?(mark.finkle) → review+
(Assignee)

Comment 18

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/b09afc8b6b61
https://hg.mozilla.org/mozilla-central/rev/2722ebdf066f
https://hg.mozilla.org/mozilla-central/rev/b09afc8b6b61
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 14
(Assignee)

Updated

6 years ago
Keywords: late-l10n
(Assignee)

Comment 20

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

[Approval Request Comment]
Improved UX for first start.
Attachment #607591 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 21

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

[Approval Request Comment]
Improved UX for first run. Mostly string/layout changes.
Attachment #609358 - Flags: approval-mozilla-aurora?
Comment on attachment 607591 [details] [diff] [review]
Patch 1. Rework setup screen.

[Triage Comment]
Mobile only - approved for Aurora 13.
Attachment #607591 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Updated

6 years ago
Attachment #609358 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 23

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

Updated

5 years ago
status-firefox13: --- → fixed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.