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
_______________________________________________
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct
