|
|
| (5 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| {| class="fullwidth-table" | | {{FeatureStatus |
| |-
| | |Feature name=Notifications |
| | style="font-weight: bold; background: #DDD;" | Feature
| | |Feature stage=Draft |
| | style="font-weight: bold; background: #DDD;" | Status
| | |Feature health=OK |
| | style="font-weight: bold; background: #DDD;" | ETA | | |Feature status note=Needs deeper specs. Has some early prototypes. |
| | style="font-weight: bold; background: #DDD;" | Owner | | }} |
| |- | | {{FeatureTeam |
| <section begin="status" />
| | |Feature product manager=Chris Blizzard |
| | [[Platform/Features/Notifications|Notifications]]
| | |Feature additional members=Jonas Sicking, Doug Turner, Johnny Stenback, Ben Turner (browser API review) |
| | {{StatusHealthy|status=Needs deeper specs. Has some early prototypes.}}
| | }} |
| | Unknown
| | {{FeaturePageBody |
| | Christopher Blizzard | | |Feature overview=Notifications is a feature that makes it possible for web-based applications to send messages from applications to users. These messages can either be delivered as a popup bubble or can be delivered to an application as an API callback and then processed. It should be possible to deliver messages even when a page isn't open and have them handled. It should also be possible to do this on desktop or mobile, with the same API and backend. |
| <section end="status" />
| |
| |- | |
| |}
| |
| | |
| == Summary ==
| |
| | |
| '''Developer Story'''
| |
| | |
| A Gmail developer wants to be able to tell Gmail users that they have new mail, even when they don't have Gmail open in a tab. She sets up a service at Google that browsers can connect to to receive updates on new data. She also writes client-side code that registers with the service using the user's Gmail ID and - based on the user's permission - can receive and process messages. This client-side code is based on a JavaScript worker that is activated when there's a notification. The worker can then send an immediate notification or batch up data in the background, based on a preference that the user set on Gmail. The background worker can also create a new tab on demand and load Gmail, passing the notification data along as information to control what Gmail loads.
| |
| | |
| '''User Story'''
| |
| | |
| A Gmail user wants to get notifications on her desktop when she gets new mail. She doesn't get very much mail, and the mail that she does get is often important. And she doesn't leave Gmail open in a tab all the time. So she signs into Gmail and clicks the "Tell me when I get new mail" button. The browser asks her if she wants notifications and she says yes. She closes Gmail and any time mail shows up she gets mail a Notification is displayed on her desktop. When she clicks on the Notification bubble, gmail is loaded and opened to the new mail that was listed in the Notification Bubble.
| |
| | |
| '''Feature description'''
| |
| | |
| Notifications is a feature that makes it possible for web-based applications to send messages from applications to users. These messages can either be delivered as a popup bubble or can be delivered to an application as an API callback and then processed. It should be possible to deliver messages even when a page isn't open and have them handled. It should also be possible to do this on desktop or mobile, with the same API and backend. | |
|
| |
|
| Different phases for this feature will add functionality over time. | | Different phases for this feature will add functionality over time. |
| Line 38: |
Line 21: |
|
| |
|
| Phase 4: Define how messages can be delivered without a page being opened. Define a way to create a page or process a message without a page being open. (Think worker threads.) Demo how pages and notifications can be created on demand in response to a message. | | Phase 4: Define how messages can be delivered without a page being opened. Define a way to create a page or process a message without a page being open. (Think worker threads.) Demo how pages and notifications can be created on demand in response to a message. |
| | |Feature users and use cases=; Developer Story |
| | : A Gmail developer wants to be able to tell Gmail users that they have new mail, even when they don't have Gmail open in a tab. She sets up a service at Google that browsers can connect to to receive updates on new data. She also writes client-side code that registers with the service using the user's Gmail ID and - based on the user's permission - can receive and process messages. This client-side code is based on a JavaScript worker that is activated when there's a notification. The worker can then send an immediate notification or batch up data in the background, based on a preference that the user set on Gmail. The background worker can also create a new tab on demand and load Gmail, passing the notification data along as information to control what Gmail loads. |
|
| |
|
| == Team ==
| | ; User Story |
| | | : A Gmail user wants to get notifications on her desktop when she gets new mail. She doesn't get very much mail, and the mail that she does get is often important. And she doesn't leave Gmail open in a tab all the time. So she signs into Gmail and clicks the "Tell me when I get new mail" button. The browser asks her if she wants notifications and she says yes. She closes Gmail and any time mail shows up she gets mail a Notification is displayed on her desktop. When she clicks on the Notification bubble, gmail is loaded and opened to the new mail that was listed in the Notification Bubble. |
| This feature requires a combination of people spread across services and applications.
| | |Feature landing criteria=1. We need to feel that the public web API is solid enough to put into a release. Prefixed is OK, or private, depending on if we want to put this on a standards tracks or re-use existing APIs (like Event Source.) |
| | |
| * '''Feature Manager''': TBD - project mgr in Services
| |
| * '''Lead Developer''': TBD
| |
| * '''Product Manager''': Christopher Blizzard
| |
| * '''API Review''': Jonas Sicking, Doug Turner, Johnny Stenback.
| |
| * '''QA''': TBD
| |
| * '''UX''': TBD
| |
| * '''Accessibility''': TBD
| |
| * '''Security''': TBD
| |
| * '''Privacy''': TBD
| |
| | |
| Team list should make it clear who to ask about what, and who to ping when they're needed. If you do not need someone in a particular role (ie: Security), that's fine, just delete that line. Contact info for each person would also be handy.
| |
| | |
| == Release Requirements ==
| |
| Complete checklist of items that need to be satisfied before we can call this feature "done".
| |
| | |
| == Next Steps & Open Issues ==
| |
| Either the next set of tasks that need to happen to move this project along, or (ideally) the full list of project tasks/action items with things crossed off as they're finished. Including the name of who's responsible for each item, and a rough ETA can be useful.
| |
| | |
| Open issues include unanswered questions, things that need to be explored, decisions that still need to be made, etc. Again, including the name of who's responsible for each item can be useful.
| |
| | |
| == Related Bugs & Dependencies ==
| |
| Links to the feature tracking bug & other relevant bugs; links to related plans (test plan, product marketing plan, etc.); notes about things that depend on this, etc.
| |
| | |
| == Risks ==
| |
| Identify, prioritize, track and communicate any risks associated with this feature/project.
| |
| | |
| == Use Cases ==
| |
| Everyone loves use cases, so you should provide them if you can (and where it makes sense). The [[ChannelSwitching/ChannelSwitchingFeature#Use_Cases|Channel Switcher]] Feature Page has some good examples.
| |
| | |
| == Designs == | |
| Any and all mockups, design specs, tech specs, etc. Either inline or linked to.
| |
| | |
| == Test Plans ==
| |
| Any and all test plans and strategies. Either inline or linked to.
| |
| | |
| == Goals ==
| |
| The high level goals for the feature (which the release requirements checklist should fulfill). These are the guiding light and overall vision for the feature. Refer to this if there is confusion or are disputes about direction, designs, planning, etc.
| |
| | |
| == Non-Goals ==
| |
| Things we are specifically not doing or building as part of this feature.
| |
|
| |
|
| == Other Stuff ==
| | 2. We'll need to have a server set up so that developers can use this feature easily without having to launch their own services. |
| Can include things like:
| |
| * Competitive landscape
| |
| * Research & references
| |
| * Whatever else is useful to the project.
| |
|
| |
|
| == Legend (remove if you like) ==
| | 3. Although this is not required for initial launch, we need to have a clear path on Mobile and make sure that any APIs we deploy will work on Mobile as well as desktop. Also required is a path that lets us deploy at scale on Mobile in a way that won't drain batteries excessively. |
| {| class="fullwidth-table"
| |
| |-
| |
| | {{StatusHealthy|status= }}
| |
| | Healthy: feature is progressing as expected.
| |
| |-
| |
| | {{StatusBlocked|status= }}
| |
| | Blocked: feature is currently blocked.
| |
| |-
| |
| | {{StatusAtRisk|status= }}
| |
| | At Risk: feature is at risk of missing its targeted release.
| |
| |-
| |
| | '''ETA'''
| |
| | Estimated date for completion of the current feature task. Overall ETA for the feature is the product release date.
| |
| |}
| |
|
| |
|
| __NOTOC__
| | 4. We'll have to go through security reviews for the design and implementation. |
|
| |
|
| Please remove this line and any non-relevant categories below. Add whatever other categories you feel are appropriate.
| | 5. We should try and stagger the release into useful bits to start getting useful feedback. Stages are laid out above. |
|
| |
|
| [[Category:Features]]
| | 6. The implementation should be deploy-able and support-able. |
| [[Category:Firefox]]
| | }} |
| [[Category:Platform]]
| | {{FeatureInfo |
| [[Category:Services]]
| | |Feature priority=Unprioritized |
| [[Category:Mobile]]
| | |Feature roadmap=Platform |
| [[Category:Other]]
| | |Feature list=Platform |
| | |Feature engineering team=WebAPI |
| | }} |
| | {{FeatureTeamStatus}} |