|Status note||Needs deeper specs. Has some early prototypes.|
|Product manager||Chris Blizzard|
|Directly Responsible Individual||`|
|Product marketing lead||`|
|Additional members||Jonas Sicking, Doug Turner, Johnny Stenback, Ben Turner (browser API review)|
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
- 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.
Stage 2: Design
5. Functional specification
6. User experience design
Stage 3: Planning
7. Implementation plan
Quality Assurance review
Stage 4: Development
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.
|Theme / Goal||`|
Team status notes