> > It's not obvious to me when that "appropriate time" would be though; do >> users who miss seeing the option during signup have to discover it by going >> into their sync preferences, or are we considering some sort of in-product >> messaging to advertise it? > > > I believe the intention is that when a doorhanger is shown for the user to > opt-in to the feature itself (ie, to storing address/credit-card > information locally), there will be an additional checkbox shown for sync > users where they can also opt-in to syncing the data. >
The original case envisioned for tracking declined was that a device can choose to show a doorhanger at the granularity of the individual sync, typically on a first or second sync of a capable device, or when a feature is first added to the browser for existing users. If you're an existing autofill user on desktop, and you sign up for FxA on your iOS device, then when you sign in on your desktop and we begin syncing we can say "Do you want to sync your autofill data?" If you're using an older version of Firefox and upgrade, we can see that we're now able to sync autofill, and offer it to the user during their first sync after restarting, or at any later date. At the moment of syncing we also know which devices you use, and we enhanced the client record format in part to allow better decision making around this sort of thing, so we could e.g., only offer to turn on syncing if you have another desktop of a version that can use the data, and prompt accordingly: "Do you want to sync your autofill data to Firefox on Richard's iMac? You can change your mind later in Preferences.". * Old browsers that do not support the feature, will write the new >> values into declined engines list on the server without understanding what >> it is > > > > Desktop does this, but TBH I'm not quite sure what Android does (and IIUC, > iOS doesn't even offer these choices?) > All Sync 1.5 clients will preserve the declined list. > Is that accurate? If a user opts-in to the new datatypes when signing up >> on Android, and then signs in on their desktop device, how does the new >> device know to respect the user's original opt-in? >> > > hrm - that's a good point. When Desktop signs in it can look in > "declined", but the lack of the new engine there could mean either (a) user > was presented with the option and accepted the engine or (b) user created > the account before the engine was first offered. > > Bugger. I'll need to think about this some more and welcome all other > thoughts. Richard, do you have any here? Maybe we should also write > "accepted"? > On iOS we default to enabling *desktop* engines that we don't sync <https://github.com/mozilla-mobile/firefox-ios/blob/master/Sync/SyncStateMachine.swift#L24>, unless the user declined them — they're mentioned in the copy, so we go ahead and turn them on. We're establishing/following the guideline that absence from both `engines` and `declined` means that the creating device didn't know about that engine. I'd suggest that we shouldn't present options to a user without writing them into one of the two places, even if we write with version=0 <https://github.com/mozilla-mobile/firefox-ios/blob/master/Sync/SyncStateMachine.swift#L47> and upload no data, which is essentially an enablement placeholder. I think that rule eliminates the ambiguity, no? Present in declined = user said no; present in engines = user said yes; not present = user didn't make a choice. >From the dialogs above, "Yes" would write to engines, "No" would write to declined, and dismissing the dialog would take no action (perhaps writing a pref to avoid reprompting too soon). > In the mean time though, it would still be interesting to know what the UX > *preference* is for this, even if it turns out we might need to adjust that > to suit reality :/ Quite!
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
