On Tue, Jun 13, 2017 at 2:22 PM, Mark Hammond <[email protected]> wrote:
> On 6/13/17 2:05 PM, Ryan Kelly wrote: > >> On 13 June 2017 at 12:22, Richard Newman <[email protected] <mailto: >> [email protected]>> wrote: >> >> Bear in mind that we have 'declined' in meta/global, which is >> intended to support exactly this scenario. >> >> A user signing up on Android or iOS can upload a meta/global without >> "payments" (or whatever), but it also won't be in 'declined'. >> >> Desktop can use that hook — a locally supported engine that's >> neither remotely enabled nor remotely declined — to offer the new >> data type at the appropriate time. >> >> >> 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. > It makes sense to the users new to autofill, and I’ve already covered the scenario in autofill ux spec: https://mozilla.invisionapp.com/share/AP8TFZ22G#/185446463_1-5_Autofill The doorhanger[1] only shows up **one time** when users login FxA and encounter the *first* form. However, it doesn’t cover the case that users have used autofill feature before *login*. For example, users sign up FxA in computer A when it’s Firefox 55, and use another computer B without login FxA. Now Firefox in computer B is updated to 56, and users start to use autofill in B without login FxA. If they login FxA afterward after using autofill for a while, there is no hint to tell users to sync autofill. So I prefer, in this case, users would see sync autofill option in *login page* instead of doorhanger. In login page, users focus more on what will change if they login so I think it makes perfect sense to inform users that “autofill will be sync too” at the moment, especially users is already using autofill and know what it is. However, if we use doorhanger to handle sync, it would be a different door hanger from doorhanger[1] and it makes less sense to me to show sync option at the moment when users focus on autofilling a form. > > 1) We always offer these new engines in anticipation of the user >> eventually using a version of Firefox that supports them. The main >> issue >> with this is that it may cause confusion for the user - for example, >> if >> they create an account on Android, they may be confused when they >> can't >> find the addresses/credit-card feature on that platform. Similarly for >> users who happen to sign up on, say, Firefox ESR (which presumably >> will >> not get this support until the next ESR release). >> >> >> To be sure I understand what's proposed here: >> >> * FxA always shows the new options in the choose-what-to-sync screen, >> defaulting them to unselected >> > > I believe the intent is to default them as selected. Note that the user > may or may not have opted in to the local feature at this point. This is > much like "passwords", where the user may be presented with the option to > sync passwords, with the default being true, even though they may not yet > have opted in to actually saving passwords locally (or even may have > explicitly disabled the feature in about:prefs) > To me, it’s a little weird to see autofill in one of my sync options but I cannot find anywhere to use it on my phone. If we prefer to go for this proposal, could we at least inform users that autofill only available in desktop (for now)? > > * If the user does not select the new datatypes, then we include them in >> "declinedSyncEngines" when we message login state to the browser, and: >> * New browsers that support the feature, will know not to sync it, >> and will write it declined engines list on the server >> > > Given it will default to enabled, this will be the case if the user > de-selects it - but yeah. > > * 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?) > > * If the user does select the new datatypes, then they don't show up in >> "declinedSyncEngines", and: >> * New browsers that support the feature will turn on syncing of >> those types, writing them explicitly into /meta/global on the server >> * But old browsers that don't support the feature will not do >> anything different >> > > There's a little bit of handwaving here, as the local preferences for > these engines will need to default to disabled, so when existing Sync users > get an upgraded Firefox with support for these engines they will not be > automatically enabled. Thus, it's probably not strictly necessary for these > engines to end up in declined (even though they will), but probably *is* > necessary for Desktop to be confident that an engine was actually > *offered*, so the local preference for the engine is changed from its > default disabled state to enabled. > > IOW, the webchannel handling code at http://searchfox.org/mozilla-c > entral/source/services/fxaccounts/FxAccountsWebChannel.jsm#283 will need > to get smarter - it currently only explicitly disables engines, but will > need to change to explicitly enable engines we know were offered but were > not declined. > > 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"? > > 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 :/ > > Cheers, > > Mark > -- Juwei
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
