Hi all, Thanks for summarizing this. I think it will help to lay out the user behaviors that would necessitate various forms of syncing (much of which have been alluded to by comments so far):
*Task continuity (switching devices mid-way through a task to complete a single goal)* This could be in a continuous flow (eg. Look up the map for a location on desktop and then it's already queued up for navigation on my mobile when I get to my car). It could also be non-continuous. (eg. I start looking for a Birthday gift for my spouse on my tablet and continue a few days later on my desktop without having to re-review the same search results/links) The former is much more common (according to a 2012 study). [1] The research shows that task continuity for searching is the most common task continuity use case at the moment (could be a factor of the supported features on competitors' devices at the moment - this means the person literally re-searches for the same thing on the second device and picks up where they left off). Further, for sequential device usage, the escalation path is almost always from a smaller screen to a larger one. (ie. start the task on a smartphone and end on a desktop) [2] I think it will be worth listing out and prioritizing each of the specific task continuity scenarios. I can help document that (which can turn into our requirements). *Ubiquitous content access (I can get to my content no matter what device I use)* This certainly has areas of overlap with the above, but many use cases are somewhat different. (eg. no matter what device I'm on I have access to my music library) This one covers things like media content. Again, I'll try to document these. *Device switching (permanently switching devices or reflashing a device)* Certainly if all content is synced for use cases 1/2, this may not be necessary for much of the content, but this is where things like device settings could be restored. This is most important for when users go to buy a new device (and also for dogfooding). While important, it doesn't have the impact of the above areas on the daily life of users. *Simultaneous device usage (using two or more devices simultaneously)* There are two types: unrelated and related simultaneous usage. (eg. the former might be checking email while watching TV, the latter might be looking up plot details while watching a TV show) This may not be a priority immediately and is MUCH larger in scope, but I think there might be opportunities to offer value to users by doing things like pre-fetching relevant content on the smartphone based on what the user is watching on their FxOS powered TV. Peter [1] http://services.google.com/fh/files/misc/multiscreenworld_final.pdf [2] http://blog.gfk.com/2014/03/finding-simplicity-in-a-multi-device-world/ On Tue, Apr 14, 2015 at 7:34 PM, Richard Newman <[email protected]> wrote: > I also tend to think that the current Firefox Sync solution could be the >> way to go for this kind of data, at least initially. We can start working >> on making Firefox OS use the existing Firefox Sync platform for browser >> related data like history, bookmarks, form autocomplete data, >> requestAutocomplete data, passwords, etc. We can expose a system only API >> to content to allow Gaia to use the existing infrastructure. >> > > Interop with other Firefoxen definitely makes sense. > > Two words of warning: > > 1. As I cautioned in Bug 824026, I think the desktop Sync codebase is > probably not reusable in this context, so you would have to do some > non-trivial work. > > 2. Adding new datatypes to Sync isn't a quick and easy affair, and we are > definitely moving in the direction of deploying new special-purpose > FxA-attached services instead of stitching new kinds of data into the > legacy Sync system. > > > Just like Calendar and Email, we can use 3rd party services to sync data >> with (i.e. Google, Outlook, Facebook (maybe not anymore)), but we still >> need a solution for locally generated content like new contacts or merged >> contacts. There has been some previous efforts to do this for contacts in >> the past [2]. >> >> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=976837 >> > > And Bug 1019787 (and Bug 859306, and …). > > Related to this effort: > > https://etherpad.mozilla.org/firefoxos-sync > > > > >> One of the ideas that came from the v3 ideation process was task >> continuation. Specifically, the example of an instant messaging app that >> users could use from any device (desktop, mobile) to send and receive >> messages (including SMS or MMS if a phone number or a RIL enabled device is >> "connected"). I can start a conversation on my phone and finish it on my >> laptop (like Whatsapp does now). This idea is even more attractive if you >> add WebRTC to the equation. >> > > Definitely try to sync up with what desktop and mobile UX has been > thinking in this area, particularly Darrin and Madhava. > > > > I would say that installed apps synchronization should also be part of the >> browser related data that I believe that could be initially managed by >> Firefox Sync. I would love to be able to have the FxOS Music app running on >> my desktop via WebRT just by enabling Firefox Sync on my browser or the >> Telegram app being installed on my laptop when I install it on my FxOS >> device, for example. >> > > Amusingly, we built something called AITC (Apps In The Cloud) about 3 > years ago. It was decommissioned and removed from the tree a little later. > > >> * Arbitrary data - Handle data syncing for arbitrary web content >> >> >> This is where things are more interesting. IMHO the hardest part here is >> to create the more generic possible solution that could enable 3rd party >> developers to use our sync platform. >> > > Yeah, this is a big challenge. Dropbox's structured data API is a pretty > good general solution to this problem (with some drawbacks, of course). > > >> 1. At Mozilla we are in the unique position to focus on providing the >> user with the choices that they want over attempting to leverage features >> to get users locked in to our platform, and I think we should focus on >> that. Sync contacts with Google, Photos with Dropbox, SMS's with our own >> storage services etc. >> >> >> Yes! User choice is key. >> > > Thus far this is not something we've put a ton of effort into with FxA. In > theory it's possible to attach arbitrary services to your FxA, implementing > various syncing needs. See https://wiki.mozilla.org/User_Services/Meta > for one way to do this. > > In practice we have not done so, and each client hard-codes its service > URLs. > > I'd like to see us move in the direction of more flexibility here. > > >> >> 2. The characteristics of those sync uses cases (that were not >> exhaustive) are very different, I dont think we will have a 'data sync >> solution', some of the use cases may converge (App sync and SMS), however >> syncing files with drop box looks and acts hugely different from syncing >> history in the browser and I dont think we can try to force a single >> solution for both cases. >> >> One thing we've learned from Firefox Sync is that it's almost impossible > to make the right tradeoffs for all of these datatypes. > > I generally advise "reuse, don't combine" — make separate services that > might, if convenient, share an implementation. The current Reading List > service, for instance, is quite generic and could be repurposed for storing > contacts… but I wouldn't suggest that we make the same service handle both > RL and contacts! > > _______________________________________________ > dev-gaia mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-gaia > >
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
