Features/Jetpack/Jetpack-Chrome-mods

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

Status

Jetpack Chrome-mods
Stage Draft
Status `
Release target `
Health OK
Status note `

{{#set:Feature name=Jetpack Chrome-mods

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

Team

Product manager Dave Mason
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=Dave Mason

|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

Firefox has always presented itself to developers as a browser that allows customization. While this can often be painful from the point of view of user experience, it also provides great power in extensibility and innovation. Jetpack has always embraced the idea of modification and extension but only for shallow integrators where we felt some responsibility to help direct better user experience guidelines through offering only elements that would lend themseleves to that better experience. While that does a great deal to help keep the experience clean, it also frustrates those who want to integrate more deeply into the browser. With a new focus on Deep Integrators we want to investigate what kinds of modifications we can allow SDK developers to make to the desktop UI.

Chrome mods should allow the developer to easily alter Firefox chrome, possibly in a manner that is very similar to page-mods with the exception that the chrome being altered must first be properly identified before the developer can alter that element.

The first phase of the work will be to identify what sorts of modifications developers want and that could be made safely.

The second phase should be to develop an API for making those changes.

Subsequent phases will involve implementation dependent on the previous phases.

2. Users & use cases

It is part of the initial work to identify what the users and use cases are here.

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

` {{#set:Feature open issues and risks=` |Feature overview=Firefox has always presented itself to developers as a browser that allows customization. While this can often be painful from the point of view of user experience, it also provides great power in extensibility and innovation. Jetpack has always embraced the idea of modification and extension but only for shallow integrators where we felt some responsibility to help direct better user experience guidelines through offering only elements that would lend themseleves to that better experience. While that does a great deal to help keep the experience clean, it also frustrates those who want to integrate more deeply into the browser. With a new focus on Deep Integrators we want to investigate what kinds of modifications we can allow SDK developers to make to the desktop UI.

Chrome mods should allow the developer to easily alter Firefox chrome, possibly in a manner that is very similar to page-mods with the exception that the chrome being altered must first be properly identified before the developer can alter that element.

The first phase of the work will be to identify what sorts of modifications developers want and that could be made safely.

The second phase should be to develop an API for making those changes.

Subsequent phases will involve implementation dependent on the previous phases. |Feature users and use cases=It is part of the initial work to identify what the users and use cases are here. |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=` }}

Feature details

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

{{#set:Feature priority=Unprioritized

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

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