Thank you Mark for clarifying all the complicated use cases! You always have the clearest logic in the thread :)
I've discussed your idea( which is to ignore the edge case for now) with Joe C and we both agree on it. Since it's not the-end-of-the-world use case and users still can go to preferences to enable autofill sync, I guess we can ignore this case in 56. So it sounds good to me (and Joe)! Juwei On Wed, Jun 14, 2017 at 5:17 PM, Mark Hammond <mhamm...@mozilla.com> wrote: > On 6/13/17 6:10 PM, Juwei Huang wrote: > >> 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. >> > > Thanks the the pointer to that mockup. > > Thinking more about this, and given the other sub-thread re Android and > rnewman/rfkelly's comments, I think what we need to do is, roughly, (2). > The lazy me wanted (1), but I don't think that works. > > * Desktop will add support for the engines, disabled by default. > > * For account creation, only Desktop Firefox 56+ will be offered the new > engines. It will flip the state of the new engines to enabled if they are > selected and will update the "declined" set otherwise. > > * Android can support the round-tripping engine (bug 1360359), but *will > not* have that engine exposed in any UI - neither the web-based "create > account" flow, nor the local "sync options". It will only get that UI > support when it gets the autofill feature, at which time it will replace > that round-tripping engine. In the meantime, it will do the round-trip sync > whenever they aren't. Grisha, does that sound good? > > So in effect, people creating an account on Android/ESR will be in the > same position as all existing users are. > > 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. >> > > Yes, that's a good point. > > So I prefer, in this case, users would see sync autofill option in *login >> page* instead of doorhanger. >> > > For various reasons, I don't think we can make that happen for 56 (the > server simply doesn't know if it applies at signin time, and the client > doesn't know as it's not yet signed in.) > > However, I expect these users are somewhat edge-cases. The absolute > worst-case is that they need to visit about:prefs and enable the engine - > and that might be OK for MVP. > > 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. >> > > Yes, we could show a slightly amended doorhanger at any time. I agree that > simply interacting with the feature may not be a good time, but maybe it's > not that bad given these users are unfortunate to be in this state at all. > Or maybe just the next time they save a profile (ie, at the same time we > would have first prompted for local saving)? > > 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)? >> > > As above, the lazy me was hoping we could get away with just showing it > everywhere, but I'm now convinced that's not going to work - Android > shouldn't offer this engine. > > So, my current thinking says the UX looks roughly like: > > * Desktop user creating account on 56+: new engines offered at creation > time. May or may not have opted in to the local feature, but it doesn't > matter - that's the simple case. > > * Desktop user upgrading to 56 with existing Sync account: (ie, existing > sync users). New engines appear in about:prefs but are disabled. First time > doorhanger shown for the local feature the "also sync?" checkbox is in the > doorhanger, and this flips the new engines to enabled. > > * Android/ESR user creating an account (1): Not presented with the new > engines. Signin in to the account on desktop will *not* present the engines > - hopefully it's a fairly new profile so they haven't yet opted in to > formautofill on the profile. > > * Android/ESR user creating an account (2): Not presented with the new > engines. Signin in to the account on desktop, but *have* already opted in > to the local feature. This is Juwei's scenario above - worst case, must > find about:prefs, best case is that we show a modified doorhanger. > > And what this means to engineering: > > * New engines are landed with pref defaulted to disabled. > * FxAccounts/Browser handshake is extended to indicate if the new engines > should be enabled, and whether they were actually shown. Or maybe UA sniff > - we can work those details out. > * Desktop changes a little so if it is sure the new engines were displayed > and they weren't declined, we explicitly enable the engine. > * Android/iOS doesn't change at all. > * The "declined" feature basically does as it was designed to do - the > engine will not be marked as "declined" when the account is created on > Android (and obviously isn't marked as declined for existing users). Yay > Richard ;) > > So the only 2 outstanding questions I see are: > > * This *doesn't* handle a case where the *entire* autofill feature is > disabled for some obscure reason (eg, addon breakage? Something else?). I > propose we commit to this feature in 56+, so even if the entire feature > *is* disabled, we assume it is temporary and still offer the engine and > continue as normal, assuming it will be back any second now :) > > * The edge case from Juwei (ie, somehow already have opted in to the local > feature without being asked about sync) is, largely, ignored - we make a > best-effort for a modified doorhanger, but would accept those users might > need to visit about:prefs in the worst case. > > Does that sound OK? > > Thanks, > > Mark > -- Juwei
_______________________________________________ Dev-fxacct mailing list Dev-fxacct@mozilla.org https://mail.mozilla.org/listinfo/dev-fxacct
