Improved missing plugin experience
Status
| Improved missing plugin experience | |
| Stage | Planning |
| Status | ` |
| Release target | ` |
| Health | OK |
| Status note | ` |
{{#set:Feature name=Improved missing plugin experience
|Feature stage=Planning |Feature status=` |Feature version=` |Feature health=OK |Feature status note=` }}
Team
| Product manager | Asa Dotzler |
| Directly Responsible Individual | Justin Dolske |
| Lead engineer | ` |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | AndreiD |
| UX lead | Alex Limi |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
{{#set:Feature product manager=Asa Dotzler
|Feature feature manager=Justin Dolske |Feature lead engineer=` |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=AndreiD |Feature ux lead=Alex Limi |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
Our current experience when a plugin is missing is pretty abysmal, and rarely works for anything else than a very small set of plugins. We want to fix the experience for the small set of plugins that have a lot of users, and stop pretending to supply an auto-detect service for the others.
This feature falls primarily in the Experience category (from the "Discover, Experience, and Connect" vision statement.)
2. Users & use cases
`
3. Dependencies
`
4. Requirements
- Ability to detect and point to relevant locations for the major plugins
- Mozilla needs to host permanent redirect URLs for this, so we can change quickly, should downstream providers suddenly change their URLs or similar
- It should be possible to say "Don't ask me to install this plugin again"
- We should never imply that installing a plugin is absolutely necessary for the browser to function (like we kind of do today), but rather that plugins are required for certain types of content
- We should label which plugins you'll end up downloading/installing in the location where we show the "Missing Plugin" message. Right now, you don't know until you go ahead and start the process
- We want to stop using Plugin Finder Service, and instead hardcode the small list of plugins we care about to simplify the code and maintenance burden
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=Our current experience when a plugin is missing is pretty abysmal, and rarely works for anything else than a very small set of plugins. We want to fix the experience for the small set of plugins that have a lot of users, and stop pretending to supply an auto-detect service for the others.
This feature falls primarily in the Experience category (from the "Discover, Experience, and Connect" vision statement.)
|Feature users and use cases=`
|Feature dependencies=`
|Feature requirements=* Ability to detect and point to relevant locations for the major plugins
- Mozilla needs to host permanent redirect URLs for this, so we can change quickly, should downstream providers suddenly change their URLs or similar
- It should be possible to say "Don't ask me to install this plugin again"
- We should never imply that installing a plugin is absolutely necessary for the browser to function (like we kind of do today), but rather that plugins are required for certain types of content
- We should label which plugins you'll end up downloading/installing in the location where we show the "Missing Plugin" message. Right now, you don't know until you go ahead and start the process
- We want to stop using Plugin Finder Service, and instead hardcode the small list of plugins we care about to simplify the code and maintenance burden
|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 | P1 |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | User Experience |
| Secondary roadmap | ` |
| Feature list | Desktop |
| Project | ` |
| Engineering team | Desktop front-end |
{{#set:Feature priority=P1
|Feature rank=999 |Feature theme=` |Feature roadmap=User Experience |Feature secondary roadmap=` |Feature list=Desktop |Feature project=` |Feature engineering team=Desktop front-end }}
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=` }}