1152356 - Move sync datatype selections to the web

Status: RESOLVED DUPLICATE of bug 1183917

(Firefox :: Sync, defect, P3)

Description

[Ryan Feeley [:rfeeley]]

Currently when the user selects “choose what to sync” on the web, they are not presented with the sync datatype selections until after email verification in the client. This is a problem because it can collide with other messaging and often submit itself with all items checked on. We should do like Fennec and ask them on the next step if they have chosen to choose what to sync. This means removing the sync datatype selection dialog from the client.

Possibly requires coordination with fxa-content-server:
https://github.com/mozilla/fxa-content-server/issues/2303

Comment 1

[Nick Alexander :nalexander [he/him]]

I'm concerned that we have not thought this through.  Different clients support different sets of datatypes: Desktop syncs Add-ons and Preferences; Android does not; and iOS may sync a different subset for v1 (for example, not bookmarks).  This only makes sense if we actually have the fxa-auth-server own the set of datatypes (services!) attached to the Firefox Account, and we have a long history of punting on this.  I really don't want the UX to drag us to this future and find we haven't thought through the service management aspect.

We have a ticket tracking this for iOS: https://bugzilla.mozilla.org/show_bug.cgi?id=1139038.  rnewman will link in existing client tickets and rfkelly can do the same for services.  ckarlof mooted a simple static JSON record of attached services which in my opinion is good enough for v1.  But we need a coherent story for adding (and eventually removing) new services to the descriptor.

Comment 2

[Ryan Feeley [:rfeeley]]

Do you think it's better if the sync datatype selection is handled by the client like Android? Perhaps desktop and iOS could offer there’s as Android does. May even be preferable to the web. But you are right, with iOS lacking bookmarks, it requires informing the user about the new sync datatype on upgrade.

Comment 3

[Ryan Kelly [:rfkelly]]

I agree with Nick that there's a deep can of worms here.  But on the surface and in the short-term, could we not offer just the desktop choose-what-to-sync API through the web, and leave other devices to their own devices?

This is not awesome architecturally, but is inline with choices we've made so far where desktop UI depends on web content.

Comment 4

[Ryan Feeley [:rfeeley]]

Attachment: about-accounts-choose-what-to-sync.png

What if we simply moved the choice to be done up-front in the client, like in Android? See attached.

Comment 5

[Nick Alexander :nalexander [he/him]]

(In reply to Ryan Feeley from comment #4)
> Created attachment 8591699 [details]
> about-accounts-choose-what-to-sync.png
> 
> What if we simply moved the choice to be done up-front in the client, like
> in Android? See attached.

I'm a little confused by what you are showing.   (And I can't find the old version, which I think just had checkmarks in a page itself.)  Is the idea that you would get this dialog natively, via the content and client messaging over the appropriate channel?  If so, this is certainly more flexible -- but we could always have clients tell the content what datatypes are available using query parameters or similar.

But it's not hitting the real issue: our end goal is that data type elections are per-device but centrally managed.  What happens if you create your account on a device that doesn't sync some datatypes (both iOS and Android will fit this category)?  It doesn't make sense for the set of datatypes to depend on the creating device; but it's really mis-leading to show a list that includes datatypes that your devices might never be able to sync.  In Firefox Sync we added "declined" engines to meta/global to differentiate from engines your device might not know about.

It sounds like this we're intentionally scoping this away from the real goal, so I guess it's up to UX to choose whether:

1) to have the full set of engines and lie to iOS and Android, or have a creating-device specific set and screw over future Desktop devices;
2) use whichever of in-page or pop-up dialog you feel is better UX.

In this way we can simplify client implementations, especially on desktop: the "signedin" message will include a set of datatypes.

Comment 6

[Robin Bankhead]

If I could venture an opinion, keeping the user in the picture is desirable, and I'm not keen on the "what to sync" options coming late in the process -- at least, I don't want unwanted datatypes starting to sync before I have a chance to tell them not to (and even if that is not happening, I want that to be explicit).  That's what matters to me as a user.

A popup or flyout speaks to those who don't care (or who trust the defaults), because it stays out of their way unless summoned (by those who do care).

Composition of the chooser dialog: my preference would be to see all possible options, but for those unsupported on the current device to be disabled.  Two immediate thoughts: either present disabled checkboxes with tooltips or other unobtrusive element saying "not supported on this device"; or a short-form message below the checkboxes, e.g. "the following items are not supported on $YOURDEVICE: Preferences, Tabs"

UX folk may see that level of disclosure as "doing a Ratners", but anyone likely to be using sync across devices is going to figure out before long that they can't all sync the same stuff.

(FWIW)

Comment 7

[Richard Newman [:rnewman]]

For those who didn't grow up in the UK in the 80s and 90s: "doing a Ratner's" is where you call your own product "total crap", mocking your own customers.

https://en.wikipedia.org/wiki/Gerald_Ratner#The_speech

Comment 8

[Nick Alexander :nalexander [he/him]]

This discussion has not really advanced.  For iOS (Bug 1139038) I am going to handle the datatype selection like we do on Android -- prompting on Account creation -- and we're going to figure out what to do with additional datatypes some time in the future.

Comment 9

[Ryan Feeley [:rfeeley]]

Hi Nick: I've been struggling with how to respond to this for probably too long, but I think I grasp the issues. The "what" in "choose what to sync" is complicated because it varies in client and in time (as new features are added). The approach you are taking on iOS is fine, and I would be happy with that in desktop too (what is depicted in the attached, though not annotated).

The real UX problem is presenting the sync datatypes post-verification. My question for engineering is, what's the relative effort of moving it to the web versus earlier in the client? Either one solves the problem for me (though the web-based approach is slightly preferable because it's slightly unconventional that a checkbox launches a modal the way it currently does in the client).

Comment 10

[Nick Alexander :nalexander [he/him]]

(In reply to Ryan Feeley from comment #9)
> Hi Nick: I've been struggling with how to respond to this for probably too
> long, but I think I grasp the issues. The "what" in "choose what to sync" is
> complicated because it varies in client and in time (as new features are
> added). The approach you are taking on iOS is fine, and I would be happy
> with that in desktop too (what is depicted in the attached, though not
> annotated).
> 
> The real UX problem is presenting the sync datatypes post-verification. My
> question for engineering is, what's the relative effort of moving it to the
> web versus earlier in the client? Either one solves the problem for me
> (though the web-based approach is slightly preferable because it's slightly
> unconventional that a checkbox launches a modal the way it currently does in
> the client).

I think for clients doing it on the web would *easier*, since the login message received from the content server would just be richer.  Doing it with early chrome UI is functionally equivalent to me -- I'll be enriching the login message as soon the content server provides it.

For iOS v1, we're not going to allow you to choose what to sync and we're not going to display Sync checkboxes.  (This is functionally equivalent to what shipped in Firefox for Android v1, which corresponds (IIRC) to Gecko 14.)

Moving forward, this only makes sense if auth (or profile, or ...) servers own this and provide a consistent UX for "choose what services to use on this device".  So if y'all can push data type elections into the content server and make the login message richer by the end of May, rock on -- that's a step closer to the auth server owning this configuration.

Comment 11

[Ryan Kelly [:rfkelly]]

> So if y'all can push data type elections into the content server and make the
> login message richer by the end of May, rock on

Nope.  I'd like to move us in this direction, but not in this timeframe.

Comment 12

[Chris Karlof [:ckarlof]]

Work is happening in Bug 1183917.