Services/Sync/Roadmap: Difference between revisions

From MozillaWiki
< Services‎ | Sync
Jump to navigation Jump to search
m (Created page with "<section begin=summary />{{RoadmapSummary |icon=Syncicon.png |pagelocation=Services/Sync/Roadmap |pagetitle=Sync 2011 Roadmap |owner=Ragavan Srinivasan |updated=Feb 2011 |status=...")
 
(imposing sanity upon chaos)
 
Line 1: Line 1:
<section begin=summary />{{RoadmapSummary
#REDIRECT [[Services/Roadmaps/Sync/Client]]
|icon=Syncicon.png
|pagelocation=Services/Sync/Roadmap
|pagetitle=Sync 2011 Roadmap
|owner=Ragavan Srinivasan
|updated=Feb 2011
|status=Draft
|description=As an organization, we have three main areas of focus: Desktop, Mobile and Apps.  Sync and other Services (such as Identity, Social) form a critical foundational piece for each of these areas.
 
Not surprisingly, the priorities for Sync are driven a lot by what we are hoping to achieve on each of these major focus areas. Additionally, there are various areas of user pain that we should address.
}}<section end=summary />
 
== Desktop ==
This is where most of our users are. This is where they do the most of their browsing and generate most of the data that they want to take everywhere. We should sync ''more'' of this data ''transparently''. Here's a prioritized list of data types to sync:
 
* Add-ons & jetpacks
* Search engines
* Favicons
* Site specific prefs
* Client certs
 
We should tune our Syncing behavior to be more specific to the data being synced. There are a couple of options we should pursue:
 
* Move to an instant Sync model for bookmarks and stored passwords - no user action needed.
* Move to a user triggered Sync model for get up and go (send tabs to phone). This would also be instantaneous.
 
Additionally, we should implement notification based Syncing to explore efficiencies it might bring to the system (experimental).
 
Finally, as we encourage users to organize their tabs into groups (via Panorama, for example) that make sense to them, we should Sync those tab groupings to the cloud. Applications (such as Firefox, Fennec etc) may then use that meta data to display tabs in views that make the most sense on the form factor they're being viewed in. In 2011, we should move to a model where the cloud becomes the authoritative source of your tabs (and groupings) that are then streamed to your devices/applications.
 
== Mobile ==
 
There is where we ''want'' to increase our value for users the most. The current use cases of get up and go and never start from scratch are both pretty well catered to by Sync. However, there's definite room for improvement.
 
* We should provide enough meta data to enable snippet view (ala SpeedDial) for the redesigned Fennec Start Page.
* Favicons sync mentioned above also helps with instant identification.
* Implementing a Send to Phone feature would also make the get and up go experience better and more reliable.
 
In 2011, Firefox Home is becoming a web app. This means we will need to provide web access to your Sync data. The core set of data that would be immediately useful is:
 
* Your most frequently accessed sites/web apps.
* Your bookmarks.
* Your remote tabs.
 
But more importantly, we will need to implement mechanisms for web content to get access to your Sync data. One approach we should experiment with is giving users the ability to opt-in to getting web access to their Sync data by opting out of having that data encrypted client side. We should still continue to Sync over SSL.
 
== Apps ==
Our apps strategy is still in the works, but there are definite requirements on Sync. In particular, we should:
 
* Sync your list of installed web apps.
* Provide a mechanism for web apps to selectively Sync contents of localStorage.
 
Note that there is no requirement to have this information be encrypted. There is already some prototype work done by Ian from the Apps team that is documented here: https://github.com/mozilla/openwebapps/blob/master/docs/SYNC.md
 
A few other areas that we will need to work out:
 
* Performance benchmarks
* Support data format changes without requiring coordinated releases
* Offer more storage
* Evangelism to get add-on developers and app developers to store data on the Sync servers
* Engineering changes required to make Sync work with/under e10s
 
Additionally, we should add better device management controls through our web based accounts portal. In particular, users should be able to:
 
* View account activity. We already support quotas, we should add account access ala Gmail (http://mail.google.com/support/bin/answer.py?ctx=gmail&answer=45938)
 
* Deauthorize devices. Users should be able to able to stop stolen or lost devices from syncing and getting access to their precious data.
 
== What are we '''not''' doing in 2011 ==
 
* Monetization based on selling more space. Note that we should be open to other BD opportunities (such as partnering with Dropbox, for example) that could open up revenue streams to sustain Sync, but we won't be selling storage space in 2011.
 
[[Category:Roadmaps]]

Latest revision as of 18:05, 26 April 2011

Redirect to:

Retrieved from "https://wiki.mozilla.org/index.php?title=Services/Sync/Roadmap&oldid=302834"