- 1 Vision
- 2 Priorities
- 3 Roadmap
- 4 Non-Priorities
If there’s one thing that Firefox Input has taught Mozilla, its that our community is really split up into two groups of people: passive and active. The latter are contributors. They’re our SUMO, QA, Engagement, Developer, Creative and Student Reps volunteers who perform duties in those communities to build each version of Firefox.
The other type are passive community members. These are people who follow what Mozilla staff and its active community do to build Firefox. Mostly all of them have opinions about the actions performed and usually only go so far as to reply to e-mails within newsgroups. They feel like, and definitely are, stakeholders to the Mozilla mission.
Previously, those stakeholders did not have an opportunity to easily voice their concerns over the development of our product as it was being built. The Input product succeeded there; it was able to collect close to 2 Million pieces of feedback over Firefox 4′s development cycle and those pieces of feedback resulted in numerous feature and compatibility bugs filed, valuable UX insight and a much greater understanding into what our passive community thinks of the actions the community performs to help make the Internet better.
We can do better. Input offers a slew of features to view individual pieces of feedback, trends and large clusters of similar opinions. Unfortunately, all of those views are only available through its dashboard and only over the Beta and Release channels. Users are restricted to only that medium and those channels to view our data. In order to provide value, in real-time, back to the development of the product over all of its channels, Input will need to go through a major phase of innovation in 2011. The specifics into our plan are outlined below, but the overall vision for 2011 is to fuel Mozilla's product and community development engines with high-value user feedback.
Integrate user feedback into Mozilla's user services
- Build an API and work with existing Mozilla’s product services to create features that integrate with Input’s feedback database. We’ve received significant interest for the following outcomes we plan to implement within Input and other services in Mozilla.
- Product Drivers – Input will translate spikes (i.e. 1-2 magnitude’s higher than the average over a version) over specific search terms and URLs into a newly filed bug in Bugzilla. The tool would most likely poll for data over a manually-set list of terms.
- Metrics - Insert user feedback into nightly reports and dashboards.
- SUMO – Support volunteers will be able to find Input’s clustered opinions that are similar to support thread topics using an easy-to-use button per thread.
- RRRT – Input will offer triagers the option to correlate messages per version within “happy”, “sad” and “ideas” feedback types with Bugzilla bug summaries to find matches. (and possibly increment “votes”). Just like SUMO, crash-stats triagers will be able to correlate messages and URLs per version specific feedback types with comments and URLs in crash-stats’ reports over the same version.
- AMO – Add-ons developers should be able to retrieve feedback for their Add-on’s name over the “happy”, “sad”, “ideas” (release and beta versions) feedback types using a simple “see feedback” button in the Developer Hub. Another option will be to create a running list of top suggestions by users that could be solved by the development of add-ons within AMO.
Marry Input with "Big Data" approaches
- Build out and integrate with Metrics' Grouperfish clustering service. Then, experiment with the data to deliver better user satisfaction insights for Firefox and Firefox for Mobile.
- Scale to cluster over millions of pieces of feedback.
- Retrieve feedback per locale and feedback type (i.e. “happy” and “sad”) per beta version to create a world map visualization of user sentiment per locale
- Experiment with locale-based feedback to create possible stop-words for multi-language clustering
- Run Open Data experiments to our community and educational institutions to gain better insight into commonly asked questions about our userbase and the development of Firefox.
Support all development channels of Firefox and other Mozilla products
- Input's current feedback types: praise, issues and idea will be made available to all channels and other Mozilla products. We plan to remove the release dashboard and uplift the beta dashboard to support all channels in Firefox’s development cycle.
- Users will be able to give praise, issues and idea type of feedback on any build of Firefox and Firefox on Mobile.
- Users will be able view feedback submitted over any channel/build of Firefox and Firefox on Mobile.
- Mozilla staff and community will be able to retrieve more channel-specific insight
Q1: Extend Input to Major Releases
|P1||Support Firefox and Mobile Firefox Releases||[DONE]|
|P1||Open our Database to the public||[DONE]|
|P1||Stand up the Grouperfish clustering service||[DONE]|
Q2: Graduate Input into a Platform
|P1||Offer feedback submission to all channels/builds of Firefox/Firefox for Mobile||[DONE]|
|P1||Transition to ElasticSearch||[DONE]|
|P1||Release Grouperfish 1.0||[DROPPED]|
|P1||Add a feature using the Input API into, at least, one of Mozilla's user services (Metrics, SUMO, AMO, Socorro)||[ON TRACK]|
Q3: Tighten the Feedback loop
|P1||Automate rapid release version-ing instrumentation||[DONE]|
|P1||Deploy a "Tell Us More" service after submission||[DONE]|
|P1||Show trends statistics per search||[ON TRACK]|
|P2||...continue to integrate Input into Mozilla's user services (SUMO, AMO, Socorro, Bugzilla)||[ON TRACK]|
Q4: Expand onto other Mozilla products
|P1||Support Firefox Home, Add-ons and Web Products (SUMO, AMO, Socorro, etc.)|
|P2||Show a "constructivity meter" during submission|
- Request user identity on initial feedback submission - Though two-way communication can prove to be helpful in better issue triage and determining user satisfaction, this does not provide an engaging and safe portal to deliver simple feedback about the product. In fact, it's highly likely this will cause a significant drop in the volume of user feedback as a result and, thus, render the tool much less fun, engaging, simple and, more importantly, useful.