Platform/Features/Notifications: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(4 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
* '''Browser API Review''': Jonas Sicking, Doug Turner, Johnny Stenback, Ben Turner.
* '''QA''': TBD
* '''UX''': TBD
* '''Accessibility''': TBD
* '''Security''': TBD
* '''Privacy''': TBD
* '''Services/Deployment''': TBD
 
== 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=&nbsp;}}
| Healthy: feature is progressing as expected.
|-
| {{StatusBlocked|status=&nbsp;}}
| Blocked: feature is currently blocked.
|-
| {{StatusAtRisk|status=&nbsp;}}
| 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}}

Latest revision as of 17:24, 30 August 2011

Please use "Edit with form" above to edit this page.

Status

Notifications
Stage Draft
Status `
Release target `
Health OK
Status note Needs deeper specs. Has some early prototypes.

{{#set:Feature name=Notifications

|Feature stage=Draft |Feature status=` |Feature version=` |Feature health=OK |Feature 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)

{{#set:Feature product manager=Chris Blizzard

|Feature feature manager=` |Feature lead engineer=` |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=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. {{#set:Feature open issues and risks=` |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. |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.
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 dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=` |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |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.)

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

{{#set:Feature priority=Unprioritized

|Feature rank=999 |Feature theme=` |Feature roadmap=Platform |Feature secondary roadmap=` |Feature list=Platform |Feature project=` |Feature engineering team=WebAPI }}

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=` }}


Retrieved from "https://wiki.allizom.org/index.php?title=Platform/Features/Notifications&oldid=344709"