Features/Services/Notifications

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.

Status

Notifications
Stage Draft
Status In progress
Release target Q3
Health OK
Status note for first release

Team

Product manager None Assigned, One has been requested
Directly Responsible Individual Mike Connor
Lead engineer JR Colin
Security lead David Chan
Privacy lead N/A
Localization lead N/A
Accessibility lead N/A
QA lead James
UX lead None Assigned
Product marketing lead None Assigned
Operations lead Services Ops
Additional members Jeff

Open issues/risks

  • Product Decisions Needed
    • who is first real consumer?
      • AITC has expressed interest, B2G has expressed interest
    • B2g question: are they adopting it? is an addon feasible?
    • Desktop client - is an addon really a good idea?
    • Android client - is an addon a good idea?
    • [strawman] Definition of Success (one was not set)
      • Someone out side of mozilla consumes it by EOY
        • bonus points for a major social web property (fb, twitter, etc) a year after release
      • 1000 msg/day by EOY
  • Implementation Needs
    • needs privacy review
    • needs security review
      • is pending for crypto, needs scheduling
    • needs ops review
      • petef is involved
      • estimate: initial load ~100 msgs/day
    • hardware for production has not been ordered?
    • deployment timeline is in question
  • Process Needs
    • needs a Product Marketing Manager and/or Business Development Owner

Stage 1: Definition

1. Feature overview

Notifications are a way for websites to send small messages to users when the user is not on the site. iOS and Android devices already support their own push notification services, but we want to make a better notifications system available to the whole web.

2. Users & use cases

User Stories

  • Eve logs into an app/webpage called Farm which uses Mozilla notifications. She enables Farm to send her notifications. She starts playing, and navigates away to check her email (or something). Her cows grow fat in the game, Farm sends a notification that they are fat & she can sell them to another player now (possibly with a link to where she can sell them in the game). Later, her cows get too fat and risk dying of obesity, Farm sends her a notification that she has 15 minutes to put her cows on a diet or they die. Eve decides this game sends too many messages, and disables notifications from Farm.
  • Bob goes to surfwatch.com and requests a notification for Half Moon Bay. (No user info provided to site) As site conditions become favorable (good waves, low rip tide risk), surfwatch sends out notifications. That exchange can be completely anonymous, since surftwatch only needs to know "someone wanted a notification".
  • Alice wants to buy a pair of sassy shoes from Zappos.com. Sadly, they dont have her size. However, they do have a 'notify me if this size becomes available' button (which currently sends email). Often though, Alice doesn't check her email in enough time and someone else snags the one pair in the right size. If Zappos had used mozilla notifications, Alice would have seen the notification pop up on her phone and snapped them up.

More Generally

  • Email Notice -

A webapp provider wishes to communicate with their audience. The provider has a set of user tokens for their customers. They then send messages to token@mozillamessaging.com (domain tbd). Notifications parses the message, wraps the message in a useful wrapper, and then relays the message to the registered user address, thus providing the user the ability to quiet noisy providers, drop compromised addresses and otherwise manage their message delivery.

In addition, these alerts may be passed on to other devices/platforms that are running the webapp. (Note, some care should be exercised to prevent user from being "spammed" by these sorts of notifications. e.g. Same Notifications appearing on every device, email and other notification system they possess.)

  • Event Alert -
    • subclasses: Timed Alerts, Reaction Alerts, Correspondence Alert
    • A user wishes to receive alerts when an event of interest is about to

happen. The user signs up with a service, and the service receives a user token. At a significant time, the service then sends a JSON notification to that user token, which causes the notification to appear on any browser that the user is currently using.

  • Cancel Alert -

A user no longer wishes to receive alerts for a given notification. The user loads their admin and control panel and disables the queue. The user can either temporarily silence a given notification queue (in which case, notifications are still collected, but not immediately alerted to the user) or delete the queue (in which case, incoming notifications are rejected, existing notifications are removed, and the queue is no longer associated with the user.)

3. Dependencies

  • Clients
    • This product page only covers the backend system.
  • Desktop - addon?
  • B2G - ?
  • Android - addon?
  • Services Ops - deployment

4. Requirements

  • Transparency: Process MUST be transparent to user. For example, other than clicking "Yes" or "No" to a dialog of the web app requesting to send notifications, the user should not be aware of the underlying mechanics of the process.
  • Security: From the point a message leaves the sender until it arrives at its intended recipient, all communications may not be easily readable by unauthorized persons (e.g. anyone besides the sender and the recipient). By "easily" we mean it should not be trivial to decrypt a message, but take a long enough time and resources so that such effort is not viable. Encryption is optional, but the key should be provided by the client service.
  • Anonymity: Web apps MUST not know anything about user (insofar as the communication between the web app and server is concerned; if the user is logged in to GMail and signs up for notifications, then obviously Google can associate the resulting subscription with the user who created it).
  • Portability: Service MUST work with any device that supports the protocol.
  • Control: The user should be able to disable or delete any created notification channel. Upon deletion, the user should not see any additional messages sent to that channel. The sender should be notified that messages to that channel are no longer being accepted.

Non-goals

  • Not an identity solution
  • Not an instant message replacement system
  • Not a large content distribution (not files, movies). There will be a size limit.

Stage 2: Design

5. Functional specification

  • limit size is 1024 bytes per notification

6. User experience design

  • Without firm commitment from clients, there are no official UX specs.
    • Jeff's addon has ux from a community member

Stage 3: Planning

7. Implementation plan

see github

8. Reviews

Security review

security review: Back-end: https://bugzilla.mozilla.org/show_bug.cgi?id=749806 Front-end: TBD

Privacy review

data safety review: 2012/03/15 privacy review: ?

Localization review

responsibility of the consuming client. no plan of record

Accessibility

responsibility of the consuming client. no plan of record

Quality Assurance review

General Services QA

Operations review

General Services Ops

Stage 4: Development

9. Implementation

  • crypto is optional
  • Jeff has a shiny demo!

Stage 5: Release

10. Landing criteria

  • Needs at least one client
    • DOM API & DOM Crypt library
  • Needs production servers


Feature details

Priority Unprioritized
Rank 999
Theme / Goal The Web is the Platform, Establish Credible Apps System
Roadmap `
Secondary roadmap `
Feature list Other
Project `
Engineering team Services

Team status notes

  status notes
Products ` `
Engineering ` `
Security sec-review-needed bug 749806
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `