Platform/Features/Notifications
Status
| Notifications | |
| Stage | Draft |
| Status | ` |
| Release target | ` |
| Health | OK |
| Status note | Needs deeper specs. Has some early prototypes. |
Team
| Product manager | Chris Blizzard |
| Directly Responsible Individual | ` |
| Lead engineer | ` |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | Jonas Sicking, Doug Turner, Johnny Stenback, Ben Turner (browser API review) |
Open issues/risks
`
Stage 1: Definition
1. 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.
Different phases for this feature will add functionality over time.
Phase 1: Demo working notifications sent from a queue on a server to the browser. Display in a pop-up bubble only.
Phase 2: Define in-browser APIs for in-page delivery. Define a way to subscribe to events. Define a way to unsubscribe from events. (Tied to app install?) Demo delivery of messages to an in-app API.
Phase 3: Define how this integrates with mobile platforms. Demo delivery of messages to an in-app API running on mobile, delivered via SMS or some other async method.
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.
2. Users & 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.
- 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.
3. Dependencies
`
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
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. 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.)
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.
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.
4. We'll have to go through security reviews for the design and implementation.
5. We should try and stagger the release into useful bits to start getting useful feedback. Stages are laid out above.
6. The implementation should be deploy-able and support-able.
Feature details
| Priority | Unprioritized |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | Platform |
| Secondary roadmap | ` |
| Feature list | Platform |
| Project | ` |
| Engineering team | WebAPI |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
