Open Bug 1401745 Opened 8 years ago Updated 3 years ago

Discuss what is available for providing the user with Sync progress in the client

Categories

(Firefox :: Sync, enhancement, P3)

Product:
Firefox
Component:
Sync
Type:
enhancement

Tracking

()

Status:
REOPENED

People

(Reporter: rfeeley, Unassigned)

Details

Our UX performance guidelines as pretty clear [1]. Any process taking longer than 5 seconds requires more than a simple spinning wheel. Signing in to Sync on a new device can take many minutes with a large profile. We should set user expectations as best we can. What kinds of information are available that can be presented in the clients? Please discuss the "materials" we have to work with. Examples: Step 1 of 3 Step 2 of 3 Step 3 of 3 0% 25% 50% 100% 0 of 10 MB 5 of 10 MB 10 of 10 MB 10 seconds remaining 5 seconds remaining 1 second remaining Signing in to server… Shaking hands… Exchanging cards… Making a lunch date… Syncing history… Cleaning up… [1] http://design.firefox.com/photon/introduction/design-for-performance.html
We know which engines we're trying to sync, whether we're uploading or downloading each. We know if we're through FxA yet. We know if the server was blank or not. As we start download for each engine, we know (usually) how many records are downloading. As we start upload, we know (usually) how many records will be uploaded. On iOS we sync for a minute at a time, then stop; we can figure out if we have more data to grab. So we can say: Signing in… Fetching clients… Sending tabs… Downloading bookmarks… Merging bookmarks… Uploading bookmarks… Last synced two minutes ago Big first sync; more data to fetch later!
More examples: Syncing Bookmarks: 1 of 250 Syncing Bookmarks: 10 of 250 Syncing Bookmarks: 100 of 250 Syncing Passwords: 1 of 150 Syncing Passwords: 10 of 150 Syncing Passwords: 100 of 150 Syncing History: 1 of 11,500 Syncing History: 1,000 of 11,500 Syncing History: 10,000 of 11,500
(In reply to Ryan Feeley [:rfeeley] from comment #2) > More examples: > > Syncing Bookmarks: 1 of 250 > Syncing Bookmarks: 10 of 250 > Syncing Bookmarks: 100 of 250 > > Syncing Passwords: 1 of 150 > Syncing Passwords: 10 of 150 > Syncing Passwords: 100 of 150 > > Syncing History: 1 of 11,500 > Syncing History: 1,000 of 11,500 > Syncing History: 10,000 of 11,500 Is that really any better? The user seeing "Syncing Bookmarks: 100 of 250" certainly can see that progress is being made, but they have no clear idea idea of how long through the entire process they are, nor how long they can expect the entire process to take. It kinda reminds me of those progress bars you used to see which would edge their way to 80% before discovering they had extra work to do, and then jumping back down to 20% and start climbing again. I found them way more frustrating than a simple spinner as they actively mislead you - they set expectations and then trashed them. I rarely see those kinds of progress bars these days - they've typically been replaced with "this may take several minutes" And worse, even that's not really viable. Eg, with bookmarks, we'd really need something like: Incoming bookmarks: 1 of 250 Incoming bookmarks: 250 of 250 Applying bookmarks [where this probably can't have a count and will take an indeterminate amount of time depending on the bookmark structure - massive folders can take a full minute to apply the folder order ] Outgoing bookmarks: 1 of 100 Outgoing bookmarks: 100 of 100 etc or, if we try and avoid "incoming" vs "outgoing" we risk ending up with exactly that "progress bar" example: Bookmarks: 1 of 250 Bookmarks: 100 of 250 Bookmarks: 250 of 320 I agree 100% that the current situation isn't ideal, but it seems the proposed cures here are worse than the disease.
Oops, didn't intend for that text to be taken literally. What I mean is, what information can the UI have access to so that I can design the best possible progress indicator. If there are gaps in what I can know, it will affect the design. Once we've established what is available, I can work on a design that best set the expectations. I'd like it to be as visual as possible, but agree that we should avoid situations where 50% progress is in reality 5% complete.
You can know which engines we need to sync, which engine we're syncing, and which we've already synced. When we're syncing an engine, we can tell you which engine it is. Each engine sync is divided into: 1. uploading locally changed records: We can probably give you a somewhat accurate progress ratio for this part (how many we know have changed vs how many we've already uploaded). 2. downloading remotely changed records: I don't think we can give you progress for this part (but I could be wrong). It's pretty fast though, network allowing, and is considered by at least desktop to be the same as step 3. 3. applying the records we've downloaded: We could tell you how many records we've applied compared to how many are left, but they don't all take the same amount of time. We don't know how much work step 3 has will be until we do step 2. We can probably pretty get a number for how much work step 1 will take, but it's unclear how we could translate that between different engines (e.g. addons are slower to apply than history). We don't know how long 1, 2, and 3 will take with respect to each other (other than that step 3 is probably always slower than, or the same speed as step 2, I guess). I'm pretty confident we can know all of this, but it's possible I'm a bit pessimistic and there's other information we could guess at.
Ryan, does Thom's answer in comment 5 give you an idea of what's available? Are there other questions we can answer for you before you start on the design?
Flags: needinfo?(rfeeley)
Yes! Now that this has been discussed, I think we can close it. It sounds like we have enough granularity to stick with something visual. I am thrilled that we "know which engines we need to sync, which engine we're syncing, and which we've already synced".
Flags: needinfo?(rfeeley)
(In reply to Ryan Feeley [:rfeeley] from comment #7) > Yes! Now that this has been discussed, I think we can close it. Not sure what resolution to use - I guess "fixed" is OK as we actually did exactly what the bug asked :)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
OK, re-opening as I have more questions. Would a simple percentage indication work? We are thinking something like: 1. When Sync is in progress for the first five sececonds, the copy reads "Syncing…" 2. If progress takes longer than five seconds, we fade in a percentage e.g. "Syncing…    21%" If this works, and we want the numbers to increment as smoothly as possible, how should we distort the allocation of numbers? e.g. if history typically takes 1/4 of the time, it should consume 25% of the count Also… am struggling to integrate this step: "Big first sync; more data to fetch later!" Why are we not doing this all at once?
Flags: needinfo?(rnewman)
(In reply to Ryan Feeley [:rfeeley] from comment #9) > Would a simple percentage indication work? We can know up-front which engines have changes on the server. We can figure out up-front which local data has changed. We can make a reasonable approximation of how much data there is to fetch. If necessary, we can also do some slight of hand to steal 'future' percentages to add smoothness at the cost of fairness. There's some plumbing to build, but we can do a reasonable impression of a percentage. > Also… am struggling to integrate this step: "Big first sync; more data to > fetch later!" > > Why are we not doing this all at once? Because it might involve downloading multiple megabytes of data, perhaps 5000 bookmarks and 100,000 history records. We make each sync take no more than a minute for timeliness and battery reasons — while a sync is running, churning away on history, we're not sending tabs, we're not fetching new tabs or logins since the last sync, etc. etc., and we're also using bandwidth and battery at a prodigious rate. In theory, the longer we stretch it out, the more chance you'll arrive in a place with wifi or LTE.
Flags: needinfo?(rnewman)
I think you meant to reopen this, Ryan.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Thanks Richard! So is this work to be done 100% in each client? I think I have decent copy for this state: > "Big first sync; more data to > fetch later!" Something like: "Preparing next sync…" It hopefully lets the user know that there is nothing they need to do. We'll start working on motion designs for each platform.
Priority: -- → P3
(In reply to Ryan Feeley [:rfeeley] from comment #12) > Thanks Richard! > > So is this work to be done 100% in each client? Yep. We _could_ make it a little simpler by providing some hint headers with the fetch, or an endpoint like collection_counts but 'since', but that's a tiny minority of the work. > It hopefully lets the user know that there is nothing they need to do. Good idea.
OK, so we'd like to do something that works like this mockup by Eric [1]. Based on our performance guidelines [2] we need to provide additional information after 5,000ms of "Syncing…". I imagine that this UI feedback might help people who are reporting bugs. For illustration purposes, let’s say every step took two seconds, we probably would not want to be more verbose than this: Syncing… Signing in… Fetching clients… Sending tabs… Downloading bookmarks… Merging bookmarks… Uploading bookmarks… Downloading history… Merging history… Uploading history… Downloading addresses… Merging addresses… Uploading addresses… Downloading credit cards… Merging credit cards… Uploading credit cards… Downloading add-ons… Merging add-ons… Uploading add-ons… Downloading preferences… Merging preferences… Uploading preferences… Sync complete! Can we make this shorter? Collapse some types into simply "Syncing {datatype}"? As far as presentation, we don't want anything too jarring or zipping by immediately. How about timing between movement that is: 0–5000ms = Syncing… 5001ms–6000ms = {current step} 6001ms–7000ms = {current step} 7001ms–8000ms = {current step} 8001ms–9000ms = {current step} etc. until and then… Sync complete! (for 1.5 seconds) [1] https://irccloud.mozilla.com/file/gtEedW8R/sync-reloadv2.mp4 [2] http://design.firefox.com/photon/introduction/design-for-performance.html
Flags: needinfo?(rnewman)
Even with the verbose messages above, and on first syncs in particular, many of those steps will take well over 5 seconds - history will be somewhat common, and bookmarks will for heavy bookmark users.
(In reply to Ryan Feeley [:rfeeley] from comment #14) > Can we make this shorter? Collapse some types into simply "Syncing > {datatype}"? Yes: 1. Sometimes we will only download, only upload, or neither. 2. Most engines will not have an explicit 'Merging' step. Consider calling those "Applying" rather than "downloading". 3. "Syncing" would work for me, too. Perhaps use "Syncing" for most syncs, and the two-step label for first syncs? > As far as presentation, we don't want anything too jarring or zipping by > immediately. Another option is to allow each engine to begin, and if it has work to do -- a download or an upload has begun -- let it update the indicator, rate-limiting the updates. Typically tabs and clients take 100-200msec on my machine if they do work, and history takes a bit longer, perhaps several seconds. You can queue up the changes and flick through them no more than twice a second -- for a very small sync the sync will finish long before the indicator finishes ticking by, but perhaps that's satisfying, and twice per second might give a comfortable feeling of speed and predictability?
Flags: needinfo?(rnewman)
(In reply to Richard Newman [:rnewman] from comment #16) > Perhaps use "Syncing" for most syncs, > and the two-step label for first syncs? … and for history.
> Typically tabs and clients take 100-200msec on my machine if they do work, and history takes a bit longer, perhaps several seconds. Not sure if this query I made two weeks ago is relevant, but it seems like it might be: https://sql.telemetry.mozilla.org/queries/48955#131888. It shows some indication of the typical amount of time for these engines when they have any work to do (it ignores noop syncs). [Note that this includes android too, and things like recentHistory, validateBookmarks are android-specific sync engines only]. Anyway, in particular addons, clients, and bookmarks are consistently above 0.5s, but history is around the middle. I'd assume clients is slow since it needs to read two files, IIRC.
That's interesting - I wonder if we can get averages for a "first sync" (which might be OK to approximate as "first sync recorded for a device"?
Component: Firefox Sync: Cross-client → Sync
Product: Cloud Services → Firefox
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.