Labs/PAC/Contacts: Difference between revisions

From MozillaWiki
< Labs‎ | PAC
Jump to navigation Jump to search
(Created page with "{{FeatureStatus |Feature name=Delta |Feature stage=Draft |Feature status=In progress |Feature health=OK }} {{FeatureTeam}} {{FeaturePageBody |Feature overview=It's helpful to be ...")
 
No edit summary
Line 1: Line 1:
{{FeatureStatus
{{FeatureStatus
|Feature name=Delta
|Feature name=Contacts
|Feature stage=Draft
|Feature stage=Draft
|Feature status=In progress
|Feature status=In progress
Line 7: Line 7:
{{FeatureTeam}}
{{FeatureTeam}}
{{FeaturePageBody
{{FeaturePageBody
|Feature overview=It's helpful to be able to control your site-based communications from a single location and allow different sites to access the activities from other sites.
|Feature overview=It's helpful to be able to have a central repository for all of your contacts across your networks. This centralized access point also allows for easier definition of relationships and access control.


This feature will provide a way to read from user's various activity streams. Posting is already covered by F1, although small modifications may be required to make the two features work well together. For reading, it will provide an API much like F1, adding options for filtering by source site, destination site, author, recipients, content type, priority, time, tags, and possibly others.
From this repository, sites can request access to a user's social graph to increase the site's features' social relevancy, and the user can limit the scope of social graph which said site can access.


While the intended use of this feature will primarily be application-to-application, it will also trivially allow for a centralized, multi-channel "inbox" of a user's various activity streams (although significant UX work will need to be done to complete this feature if it is desired, as centralized inboxes and aggregators have consistently failed in the market).
This feature will provide such a repository and access point. Through interaction with a user's activity streams manager (Delta), the Contact Manager will also be able to know which of a user's contacts are already on sites which are requesting access to the graph, and only let the site know the relevant pieces of their social graph.
|Feature users and use cases=* For consumers, provide a centralized access point for a user's activity streams across various sites
|Feature users and use cases=* For consumers, provide a centralized access point for a user's activity streams across various sites
* For consumers, empower users to control these access relationships, connecting streams as they see fit
* For consumers, empower users to control these access relationships, connecting streams as they see fit
* For developers, provide a way to publicize a user's activity in your app
* For developers, provide a way to publicize a user's activity in your app
* For developers, Provide a way to pull down activity relevant to a user and to your app for in-app presentation of social activity
* For developers, Provide a way to pull down activity relevant to a user and to your app for in-app presentation of social activity
|Feature requirements=* We need to document existing stream data sources and APIs to make a natural and comprehensible API for developers
|Feature requirements=* Provide a centralized access point for a user's contacts across various sites
* These API and data type definitions will drive mappings to the user interface
* Empower users to control sites'  knowledge of their social graph
* UI for both configuration and use must be designed carefully and with user studies
* Through increased control, sites will gain increased user trust, and this in turn will promote social activity to permeate apps and the web
* Security and authenticity of the configuration UI must be verified and accessible to users.
* Plans for pulling data from streams and caching for responsiveness
* API "translators" (so a request to Delta's API makes the correct call to, say, Facebook's API)
|Feature ux design=* coming soon
|Feature ux design=* coming soon


The site-based prefs will be implemented in content at an about page (<code>about:streams</code>).  It will be in-content (much like [about:addons]), and is intended to build off of the mechanisms of the [[Privacy/Features/Site-based_data_management_UI|Site-based data management UI]] as appropriate.
The site-based prefs will be implemented in content at an about page (<code>about:contacts</code>).  It will be in-content (much like [about:addons]), and is intended to build off of the mechanisms of the [[Privacy/Features/Site-based_data_management_UI|Site-based data management UI]] as appropriate.
|Feature implementation notes=* no implementation yet.
|Feature implementation notes=* no implementation yet.
* should build off of F1 for communication with social services
* should build off of F1's contacts backend and the old Contacts add-on
}}
}}
{{FeatureInfo
{{FeatureInfo

Revision as of 01:36, 1 September 2011

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

Status

Contacts
Stage Draft
Status In progress
Release target `
Health OK
Status note `

{{#set:Feature name=Contacts

|Feature stage=Draft |Feature status=In progress |Feature version=` |Feature health=OK |Feature status note=` }}

Team

Product manager `
Directly Responsible Individual `
Lead engineer `
Security lead `
Privacy lead `
Localization lead `
Accessibility lead `
QA lead `
UX lead `
Product marketing lead `
Operations lead `
Additional members `

{{#set:Feature product manager=`

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

Open issues/risks

`

Stage 1: Definition

1. Feature overview

It's helpful to be able to have a central repository for all of your contacts across your networks. This centralized access point also allows for easier definition of relationships and access control.

From this repository, sites can request access to a user's social graph to increase the site's features' social relevancy, and the user can limit the scope of social graph which said site can access.

This feature will provide such a repository and access point. Through interaction with a user's activity streams manager (Delta), the Contact Manager will also be able to know which of a user's contacts are already on sites which are requesting access to the graph, and only let the site know the relevant pieces of their social graph.

2. Users & use cases

  • For consumers, provide a centralized access point for a user's activity streams across various sites
  • For consumers, empower users to control these access relationships, connecting streams as they see fit
  • For developers, provide a way to publicize a user's activity in your app
  • For developers, Provide a way to pull down activity relevant to a user and to your app for in-app presentation of social activity

3. Dependencies

`

4. Requirements

  • Provide a centralized access point for a user's contacts across various sites
  • Empower users to control sites' knowledge of their social graph
  • Through increased control, sites will gain increased user trust, and this in turn will promote social activity to permeate apps and the web

Non-goals

`

Stage 2: Design

5. Functional specification

`

6. User experience design

  • coming soon

The site-based prefs will be implemented in content at an about page (about:contacts). It will be in-content (much like [about:addons]), and is intended to build off of the mechanisms of the Site-based data management UI as appropriate.

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

  • no implementation yet.
  • should build off of F1's contacts backend and the old Contacts add-on

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=` |Feature overview=It's helpful to be able to have a central repository for all of your contacts across your networks. This centralized access point also allows for easier definition of relationships and access control.

From this repository, sites can request access to a user's social graph to increase the site's features' social relevancy, and the user can limit the scope of social graph which said site can access.

This feature will provide such a repository and access point. Through interaction with a user's activity streams manager (Delta), the Contact Manager will also be able to know which of a user's contacts are already on sites which are requesting access to the graph, and only let the site know the relevant pieces of their social graph. |Feature users and use cases=* For consumers, provide a centralized access point for a user's activity streams across various sites

  • For consumers, empower users to control these access relationships, connecting streams as they see fit
  • For developers, provide a way to publicize a user's activity in your app
  • For developers, Provide a way to pull down activity relevant to a user and to your app for in-app presentation of social activity

|Feature dependencies=` |Feature requirements=* Provide a centralized access point for a user's contacts across various sites

  • Empower users to control sites' knowledge of their social graph
  • Through increased control, sites will gain increased user trust, and this in turn will promote social activity to permeate apps and the web

|Feature non-goals=` |Feature functional spec=` |Feature ux design=* coming soon

The site-based prefs will be implemented in content at an about page (about:contacts). It will be in-content (much like [about:addons]), and is intended to build off of the mechanisms of the Site-based data management UI as appropriate. |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=* no implementation yet.

  • should build off of F1's contacts backend and the old Contacts add-on

|Feature landing criteria=` }}

Feature details

Priority Unprioritized
Rank 999
Theme / Goal `
Roadmap `
Secondary roadmap `
Feature list `
Project `
Engineering team `

{{#set:Feature priority=Unprioritized

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

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.mozilla.org/index.php?title=Labs/PAC/Contacts&oldid=345675"