Services/Sync/Push to device
Status
| Push to Device | |
| Stage | Definition |
| Status | ` |
| Release target | TBD |
| Health | OK |
| Status note | ` |
{{#set:Feature name=Push to Device
|Feature stage=Definition |Feature status=` |Feature version=TBD |Feature health=OK |Feature status note=` }}
Team
| Product manager | Jennifer Arguello |
| Directly Responsible Individual | Jennifer Arguello |
| Lead engineer | Gregory Szorc |
| Security lead | Yvan Boily |
| Privacy lead | ` |
| Localization lead | Axel Hecht |
| Accessibility lead | ` |
| QA lead | Tracy Walker |
| UX lead | Alex Faaborg |
| Product marketing lead | Jaclyn Fu |
| Operations lead | ` |
| Additional members | Ibai Garcia (SUMO) |
{{#set:Feature product manager=Jennifer Arguello
|Feature feature manager=Jennifer Arguello |Feature lead engineer=Gregory Szorc |Feature security lead=Yvan Boily |Feature privacy lead=` |Feature localization lead=Axel Hecht |Feature accessibility lead=` |Feature qa lead=Tracy Walker |Feature ux lead=Alex Faaborg |Feature product marketing lead=Jaclyn Fu |Feature operations lead=` |Feature additional members=Ibai Garcia (SUMO) }}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
The value proposition of Sync for a mobile user is "Get up and go." Push to device is specific to the user sending a particular link to a device.
2. Users & use cases
- Send a link from desktop Firefox to mobile Firefox
- Bob has Sync set up on his desktop and mobile device.
- Bob is reading a New York Times article on his desktop and has to leave, but wants to keep reading his train ride home.
- Through Firefox Desktop, Bob sends the link to the page he is on to his mobile device
- When Bob opens up his phone the page he just sent pops up.
- NOTE: Is this the use case?
- Send a link from mobile Firefox to desktop Firefox
- Bob has Sync set up on his desktop and mobile device.
- Bob is reading a New York Times article on his phone during his morning commute.
- He reaches the office and wants to keep reading on his desktop.
- Through Firefox Mobile, Bob sends the link to the page he is on to his desktop
- When Bob startups up Firefox (or goes to Firefox) the page he just sent pops up.
- NOTE: Is this the use case?
3. Dependencies
- Need better clarity on use cases before filling this out
4. Requirements
- Need better clarity on use cases before filling this out
Non-goals
- Need better clarity on use cases before filling this out
Stage 2: Design
5. Functional specification
`
6. User experience design
The following are needed from UX:
- How do we trigger the feature?
- Context menu when cursor over link?
- Context menu anywhere on page?
- Context menu on tab in tab browser?
- Other?
- Shortcut key(s) for above?
- What is the wording for above?
- What does the design of the above look like
- Do we have sub-menu's listing target devices?
- Do we have a modal window/pane?
- Limited to sending to 1 device?
- What's the behavior if Sync is not configured?
- What's the behavior if multiple devices are not configured?
- This will likely be the first time device names are seen by most users (currently buried in Sync preferences). Will that cause any issues?
- Poor device naming
- Orphaned/unused devices
- etc
- What happens when a browser receives a link?
- Is new tab opened automatically?
- Does it gain focus?
- Is new tab opened automatically?
- Anything else
Some questions may require separate answers for separate form factors.
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=The value proposition of Sync for a mobile user is "Get up and go." Push to device is specific to the user sending a particular link to a device. |Feature users and use cases=* Send a link from desktop Firefox to mobile Firefox
- Bob has Sync set up on his desktop and mobile device.
- Bob is reading a New York Times article on his desktop and has to leave, but wants to keep reading his train ride home.
- Through Firefox Desktop, Bob sends the link to the page he is on to his mobile device
- When Bob opens up his phone the page he just sent pops up.
- NOTE: Is this the use case?
- Send a link from mobile Firefox to desktop Firefox
- Bob has Sync set up on his desktop and mobile device.
- Bob is reading a New York Times article on his phone during his morning commute.
- He reaches the office and wants to keep reading on his desktop.
- Through Firefox Mobile, Bob sends the link to the page he is on to his desktop
- When Bob startups up Firefox (or goes to Firefox) the page he just sent pops up.
- NOTE: Is this the use case?
|Feature dependencies=* Need better clarity on use cases before filling this out |Feature requirements=* Need better clarity on use cases before filling this out |Feature non-goals=* Need better clarity on use cases before filling this out |Feature functional spec=` |Feature ux design=The following are needed from UX:
- How do we trigger the feature?
- Context menu when cursor over link?
- Context menu anywhere on page?
- Context menu on tab in tab browser?
- Other?
- Shortcut key(s) for above?
- What is the wording for above?
- What does the design of the above look like
- Do we have sub-menu's listing target devices?
- Do we have a modal window/pane?
- Limited to sending to 1 device?
- What's the behavior if Sync is not configured?
- What's the behavior if multiple devices are not configured?
- This will likely be the first time device names are seen by most users (currently buried in Sync preferences). Will that cause any issues?
- Poor device naming
- Orphaned/unused devices
- etc
- What happens when a browser receives a link?
- Is new tab opened automatically?
- Does it gain focus?
- Is new tab opened automatically?
- Anything else
Some questions may require separate answers for separate form factors. |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 | P2 |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | Sync |
| Secondary roadmap | Firefox Mobile |
| Feature list | Services |
| Project | ` |
| Engineering team | Sync |
{{#set:Feature priority=P2
|Feature rank=999 |Feature theme=` |Feature roadmap=Sync |Feature secondary roadmap=Firefox Mobile |Feature list=Services |Feature project=` |Feature engineering team=Sync }}
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=` }}