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  on behalf of Mark 
Hammond 

*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

meeting reminder: OKR Status Updates

[Sean McArthur]

It's been 2 weeks since our last status check in on OKR progress, so it's
time for another one. We have 3 weeks left of the quarter, so realistically
this the last update that would possibly change before the quarter ends.

OKR champions, please review the status and confidence of our top-level
priorities from this document:


https://docs.google.com/document/d/1Kg2zTmVipmxM2bqSUUcYTbznAdYIn2gI1etDjf5QVY4

As always, we start with a Show & Tell & Share (anything), if you have
something, don't forget to add yourself to the list:

  https://public.etherpad-mozilla.org/p/fxa-engineering-coordination
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct

FxA Web Coordination agenda for June 12, 2017

[Shane Tomlinson]

Miss a week's worth of meetings, and I forget that I have to send an agenda!

*Today's Theme: The end of train-89*

https://public.etherpad-mozilla.org/p/fxa-engineering-coordination

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

Re: Halving "Why is this required?"

[Shane Tomlinson]

+cc dev-fxacct because there's nothing secret here.

This is great! Two small nits:

Without additional context, "yet" doesn't provide any value. If there
are imminent plans to make Sync a full backup service and we can
link to an article explaining the coming changes, sure.

I'd also ditch "own" in "your own devices" - "your devices"
says the same thing.

Do you want me to put together a PR with these changes this week,
or do you think we'll do another round or two?

Shane


On Thu, Jun 8, 2017 at 6:22 PM, Alex Davis  wrote:

> Small edits added in bold:
>
> The Sync service isn’t a permanent backup *yet*, it’s simply a secure way
> to transfer saved bookmarks, history and passwords between your own
> devices. You should install Firefox and sync at least two devices to
> protect against losing your data if *you lose or replace a device, or
> forget your login.*
>
> Explanation:
> - Adding "yet" means we are working to make it better.
> - Forgetting password and resetting password are the same thing so... I
> thought it best to replace one of the two with lost/replaced device which
> could also result in lost data.
>
> Thoughts?
>
> --
> Alex Davis // Mountain View
> Product Manager // FxA & Sync
> (415) 769-9247
> IRC & Slack: adavis
>
> On Thu, Jun 8, 2017 at 6:37 AM, Ryan Feeley  wrote:
>
>> and for the header we can use "Why sync multiple devices?"
>>
>> On Wed, Jun 7, 2017 at 7:38 PM, Ryan Feeley  wrote:
>>
>>> Got it! What do you think? (Body)
>>>
>>> The Sync service isn’t a permanent backup, it’s simply a secure way to
>>> transfer saved bookmarks, history and passwords between your own devices.
>>> You should install Firefox and sync at least two devices to protect against
>>> losing your data if you forget your login or reset your password.
>>>
>>>
>>>
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct