Firefox/Input/Standalone Feedback Button: Difference between revisions
No edit summary |
(→Team) |
||
Line 27: | Line 27: | ||
Who's working on this? | Who's working on this? | ||
* '''Feature Manager''': | * '''Feature Manager''': Aakash Desai | ||
* '''Lead Developer''': Jono Xia | * '''Lead Developer''': Jono Xia | ||
* '''Product Manager''': | * '''Product Manager''': |
Revision as of 18:35, 15 April 2011
Feature | Status | ETA | Owner |
Provide a standalone feedback button | One or two sentence status report. | YYYY-MM-DD | aakashd |
Summary
The Feedback button (which is currently added to the toolbar in the Firefox aurora/beta branches by the bundled Test Pilot add-on) will be moved into Firefox where it becomes part of the default Toolbar Customization panel.
It would be added to the toolbar by default on Aurora and Beta builds. On Release builds it would not be added by default but the user could choose to add it through the Customization panel.
The button holds a drop-down menu containing two items, "Firefox made me happy because..." and "Firefox made me sad because...", both of which go to the Input website and pre-fill some fields.
Team
Who's working on this?
- Feature Manager: Aakash Desai
- Lead Developer: Jono Xia
- Product Manager:
- QA:
- UX:
- Security:
- Etc.
Release Requirements
- The Feedback button must show the Happy and Sad menu items and these must be tested and verified to work correctly (loading the Input pages and pre-filling them with the desired information).
- The Beta/Aurora builds must show the button by default, the Release build must not show it by default. (What about Nightly? TBD)
- The customization behavior must be tested and verified to work correctly (e.g. if the user is running Beta but chooses to remove the Feedback button through customization it must not reappear on restart)
- Switching channels must be supported -- The Feedback button has to appear when switching to Beta/Aurora and disappear when switching to Release. (Unless the user has manually modified its location, in which case the modification sticks regardless of channel?)
- The Test Pilot add-on (both the AMO version and the bundled-with-Firefox-betas version) must be modified to work with the new standalone Feedback button. This means the add-on no longer creates the Feedback button; instead it looks at the toolbar to see whether there's a Feedback button there, adding the "All your user studies" and "turn on/off user studies" menu items to the button if present, providing an alternate interface otherwise.
- The word "Feedback" must be properly localized (to something that's not unreasonably long in any language) OR replaced by some kind of language-independent icon. Same for the menu items.
Next Steps
- Separate Feedback button code from Test Pilot add-on and turn it into a patch against mozilla-central (Jono Xia)
Open Issues
- The code in Test Pilot currently looks at every loaded URL to see whether or not it's an Input website where data is to be filled in. This may be a performance issue, so we should test its impact and replace it with something more efficient if needed.
- Show Feedback button in Nightly channel or not?
- If the user has manually placed the Feedback button, should that preference override the channel setting? (I.e. the customization remains even if you switch channels?)
Related Bugs & Dependencies
- bug 649156 - Add the feedback button to the customize toolbar palette
Designs
TODO - Any and all mockups, design specs, tech specs, etc. Either inline or linked to.
Test Plans
TODO - Any and all test plans and strategies. Either inline or linked to.
Goals/Use Cases
- Users who wish to keep providing Input about Firefox through the feedback button should be able to do so even on the release channel with no bundled add-ons.
- The Test Pilot add-on should be independent of the Feedback button implementation (which allows Test Pilot to become a restartless add-on).
Non-Goals
TODO - things we are specifically not doing or building as part of this feature.
Other Documentation
Can include things like:
- Competitive landscape
- Research & references
- Whatever else is useful to the project.
Legend (remove if you like)
Healthy: feature is progressing as expected. | |
Blocked: feature is currently blocked. | |
At Risk: feature is at risk of missing its targeted release. | |
ETA | Estimated date for completion of the current feature task. Overall ETA for the feature is the product release date. |
Please remove this line and any non-relevant categories below. Add whatever other categories you feel are appropriate.