Re: "Choose what to Sync" for autofill

[Juwei Huang]

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  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 

Re: "Choose what to Sync" for autofill

[Richard Newman]

>
> * New engines are landed with pref defaulted to disabled.
>

This is a great time to point at Bug 1322428, which would go a long way
towards broadening our funnel.
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct

Re: "Choose what to Sync" for autofill

[Mark Hammond]

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 

Re: "Choose what to Sync" for autofill

[Ryan Kelly]

On 14 June 2017 at 02:11, Richard Newman  wrote:

>* 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
> ,
> 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
> 
> and upload no data, which is essentially an enablement placeholder.
>

This makes sense to me, although it's worth calling out explicitly that it
adds a dependency on client changes in Android and iOS, to ensure they
preserve this new piece of information.


> 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).
>
>
>From the FxA side, I assume this would just look like a new
"acceptedSyncEngines" field in the fxa:login message, matching the current
"declinedSyncEngines" field and providing the list of engines that were
explicitly accepted.  That seems straightforward at first glance, assuming
older clients won't blow up when they encounter an unexpected field on that
message...


   Ryan
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct

Re: "Choose what to Sync" for autofill

[Richard Newman]

>
> 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)?
>

I'm pretty sure I've seen one of rfeeley's mocks that address this for
sign-in/sign-up, because of course this is already the case for prefs and
add-ons on mobile devices. Ryan?
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct

Re: "Choose what to Sync" for autofill

[Richard Newman]

>
> 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
,
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

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

Re: "Choose what to Sync" for autofill

[Ryan Kelly]

On 13 June 2017 at 12:22, Richard Newman  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?


> 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

* 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
* 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

* 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

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?

So - what shall we do? Can we live with (1)?
>
>
Something about the edge-cases here makes me a little uneasy, but I suspect
I don't fully understand all the combinations involved.

   Ryan
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct

Re: "Choose what to Sync" for autofill

[Mark Hammond]

On 6/13/17 12:22 PM, Richard Newman 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.


Yes, thanks Richard, that's exactly what we'd use. Part of the 
complexity involves the client indicating to the FxA server what it 
should show, and part of the "user complexity" is that the engines they 
are offered will depend on what device they *first* use, so not only is 
that first choice difficult to document with (eg) a screenshot, the 
experience that new user has when on desktop is different depending on 
where they created the account.


So it's not so much that "(2) is far more complex from an engineering 
POV", it's more "(1) is slightly easier from an engineering POV and 
offers a more consistent signup process, at the cost of offering an 
engine the device doesn't yet support".


(And just to muddy the waters even more, bug 1360359 intends landing a 
"round-tripping" autofill engine on Android, so Android *will* support 
the engine but *will not* support the underlying feature - which is 
another reason I'm leaning towards (1) - it seems to keep things 
conceptually simpler)


Cheers,

Mark



Happy to explain in more detail if folks have no idea what I'm talking 
about.


-R

*From:* Sync-dev <sync-dev-boun...@mozilla.org> on behalf of Mark 
Hammond <mhamm...@mozilla.com>

*Sent:* Monday, June 12, 2017 5:30:10 PM
*To:* sync-...@mozilla.org; dev-fxacct@mozilla.org; 
autof...@lists.mozilla.org; Juwei Huang; Ryan Feeley

*Subject:* "Choose what to Sync" for autofill
[Sorry for the large cross-post, and I'm explicitly CCing Ryan and Juwei
as I'm not sure what lists they are on, and this is really a decision
for them]

When a user creates a sync account, the list of available sync engines
(aka "choose what do sync") is hosted on the Firefox Accounts server.
While it seems obvious that a version of Desktop Firefox which supports
addresses/credit-cards should be offered these engines, it's not clear
what should happen for other devices. I see 2 options:

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).

2) We only offer these engines on a platform that supports the feature -
this means that the user will see different options depending on what
device they use to create this account. The main issue with this
approach is that the user who creates an account on (say) Android will
find that these engines are disabled when they connect a Desktop device
to their account, meaning they will need to go through an additional
"opt-in" process for syncing this data on desktop - just like existing
Sync users will need to.

(1) would almost certainly make the engineering work easier, and given
it avoids additional opt-in UI later, is probably more seamless from a
UX perspective. It probably makes documentation etc easier too - it's
basically the same signup experience regardless of what platform you
use. However, I can also see that (2) has benefits.

So - what shall we do? Can we live with (1)?

Cheers,

Mark
___
Sync-dev mailing list
sync-...@mozilla.org
https://mail.mozilla.org/listinfo/sync-dev


___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct

"Choose what to Sync" for autofill

[Mark Hammond]

[Sorry for the large cross-post, and I'm explicitly CCing Ryan and Juwei 
as I'm not sure what lists they are on, and this is really a decision 
for them]


When a user creates a sync account, the list of available sync engines 
(aka "choose what do sync") is hosted on the Firefox Accounts server. 
While it seems obvious that a version of Desktop Firefox which supports 
addresses/credit-cards should be offered these engines, it's not clear 
what should happen for other devices. I see 2 options:


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).


2) We only offer these engines on a platform that supports the feature - 
this means that the user will see different options depending on what 
device they use to create this account. The main issue with this 
approach is that the user who creates an account on (say) Android will 
find that these engines are disabled when they connect a Desktop device 
to their account, meaning they will need to go through an additional 
"opt-in" process for syncing this data on desktop - just like existing 
Sync users will need to.


(1) would almost certainly make the engineering work easier, and given 
it avoids additional opt-in UI later, is probably more seamless from a 
UX perspective. It probably makes documentation etc easier too - it's 
basically the same signup experience regardless of what platform you 
use. However, I can also see that (2) has benefits.


So - what shall we do? Can we live with (1)?

Cheers,

Mark
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct