Status
| Push to Device | |
| Stage | Draft |
| Status | ` |
| Release target | ` |
| Health | OK |
| Status note | ` |
{{#set:Feature name=Push to Device
|Feature stage=Draft |Feature status=` |Feature version=` |Feature health=OK |Feature status note=` }}
Team
| Product manager | Jennifer Arguello |
| Directly Responsible Individual | Jennifer Arguello |
| Lead engineer | Gregory Szorc |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
{{#set:Feature product manager=Jennifer Arguello
|Feature feature manager=Jennifer Arguello |Feature lead engineer=Gregory Szorc |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
Add a browser feature that sends tabs/links/URIs from one device to another.
The feature will likely be implemented on top of the existing Sync platform.
2. Users & use cases
People with multiple physical devices running Firefox will be our audience. The feature will likely be highly valued on platforms that don't possess full browsing capabilities (e.g. pushing from a mobile phone to a larger form-factor).
3. Dependencies
The feature will require a configured Sync account.
4. Requirements
`
Non-goals
`
Stage 2: Design
5. Functional specification
`
6. User experience design
`
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
Since the feature is utilizing Sync, all data will be encrypted on the client side and stored on Mozilla's servers such that Mozilla cannot decrypt the data.
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
The feature can basically be boiled down to the following actions/functions:
1) Send a <thing> to a device, X 2) Receive a <thing> and do something with it
With the current scope of the feature, a <thing> is merely a URI.
We have 2 choices for the implementation inside the Sync framework:
1) Treat pushes as commands. 2) Treat pushes as a synchronization engine.
Depending on the feature requirements, we could go either way. But, if we don't have any requirements for maintaining a set of sent objects, then we probably gravitate to 1, as it is simpler and would approximate what is actually happening.
Assuming we go with the command approach, we can implement the core of the feature today, with the callback for the action on receipt of a URI stubbed out. Then, we can plug make the UI modifications and wire everything together, and we should be set!
Stage 5: Release
10. Landing criteria
` {{#set:Feature open issues and risks=` |Feature overview=Add a browser feature that sends tabs/links/URIs from one device to another.
The feature will likely be implemented on top of the existing Sync platform. |Feature users and use cases=People with multiple physical devices running Firefox will be our audience. The feature will likely be highly valued on platforms that don't possess full browsing capabilities (e.g. pushing from a mobile phone to a larger form-factor). |Feature dependencies=The feature will require a configured Sync account. |Feature requirements=` |Feature non-goals=` |Feature functional spec=` |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=Since the feature is utilizing Sync, all data will be encrypted on the client side and stored on Mozilla's servers such that Mozilla cannot decrypt the data. |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=The feature can basically be boiled down to the following actions/functions:
1) Send a <thing> to a device, X 2) Receive a <thing> and do something with it
With the current scope of the feature, a <thing> is merely a URI.
We have 2 choices for the implementation inside the Sync framework:
1) Treat pushes as commands. 2) Treat pushes as a synchronization engine.
Depending on the feature requirements, we could go either way. But, if we don't have any requirements for maintaining a set of sent objects, then we probably gravitate to 1, as it is simpler and would approximate what is actually happening.
Assuming we go with the command approach, we can implement the core of the feature today, with the callback for the action on receipt of a URI stubbed out. Then, we can plug make the UI modifications and wire everything together, and we should be set! |Feature landing criteria=` }}
Feature details
| Priority | Unprioritized |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | ` |
| Secondary roadmap | ` |
| Feature list | ` |
| Project | ` |
| Engineering team | ` |
{{#set:Feature priority=Unprioritized
|Feature rank=999 |Feature theme=` |Feature roadmap=` |Feature secondary roadmap=` |Feature list=` |Feature project=` |Feature engineering team=` }}
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}