Closed Bug 729532 Opened 10 years ago Closed 10 years ago
Improve first-run profile import experience
569.81 KB, image/png
5.44 KB, patch
|Details | Diff | Splinter Review|
5.16 KB, patch
|Details | Diff | Splinter Review|
3.93 KB, patch
|Details | Diff | Splinter Review|
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.
- 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.
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
Madhava, gcp, do we have agreement here on how to move forward here since this is a beta blocker?
No, this needs a proposal (urgently, the string freeze is coming up!), taking into account the first 2 comments.
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
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.
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.
- 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?
>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...
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.
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+
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+
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-
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.
Attachment #609358 - Flags: review?(mark.finkle) → review+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 14
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?
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+
Attachment #609358 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.