Features/Firefox/Easy UI Feature Testing
Status
| Easy UI Feature Testing and "Success Evaluation" (integrate TestPilot like features) | |
| Stage | Draft |
| Status | In progress |
| Release target | Firefox 13 |
| Health | OK |
| Status note | ` |
Team
| Product manager | ` |
| Directly Responsible Individual | Gregg Lind |
| Lead engineer | ` |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
Open issues/risks
Ability to modify UI has potential performance, privacy implications Collecting data has Privacy implications Publishing collected data has Privacy Implications What makes a "successful" feature?
Stage 1: Definition
1. Feature overview
Right now, features can go into FX without knowing if they will be 'successful' or not. What 'success' even means is a bit nebulous!
By incorporating Test-Pilot-like features into Firefox, it makes it easier for Feature Developers to design, implement, and instrument new features.
With usual statistics (among targeted test populations), product managers can make better decisions around which features should go forward, be revised, or be removed. This removes one of the barriers to having every feature in Firefox go through usability testing.
2. Users & use cases
- A/B testing of user features
- UI experiments
- all new user features
3. Dependencies
bringing TP like code (with mechanisms for watching events, deploying modified UI elements) into main build.
4. Requirements
`
Non-goals
`
Stage 2: Design
5. Functional specification
Include TP like functionality into FX directly, making the addon superfluous, on all FX platforms.
Specific functionalities:
- record/report any event on any id-able element, with timestamp, for a user.
- choose to run a study / instrumentation on a particular subset of users
- deploy variations in UI (via restartless addon, or another mechanism)
6. User experience design
Users should be able to see submitted data, similar to current TP implementation. Users get notification of initial opt-in Users can destroy / opt-out / not submit their data.
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
`
Feature details
| Priority | Unprioritized |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | ` |
| Secondary roadmap | ` |
| Feature list | ` |
| Project | ` |
| Engineering team | ` |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | sec-review-needed | Please schedule with curtisk |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
