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-dev@mozilla.org; dev-fxa...@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-dev@mozilla.org
https://mail.mozilla.org/listinfo/sync-dev
_______________________________________________
Sync-dev mailing list
Sync-dev@mozilla.org
https://mail.mozilla.org/listinfo/sync-dev
