Firefox/Input/Roadmap/2011

	Firefox Input Roadmap
	Owner: Aakash Desai	Updated: 2012-01-24
	User feedback has proven to be invaluable to the development of the 4.0 release of Firefox and Firefox for Mobile. To further integrate user feedback into the development into Mozilla's products and community, Input's three main product priorities are to couple user feedback to various Mozilla user services, build out support for all channels of the new development process (and other Mozilla products) and experiment with our data using big data approaches in order to provide new insights.

Vision

...What's Known

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.

...Going Forward

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.

Priorities

Integrate user feedback into Mozilla's user services

Strategy

• 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.

Outcomes

1. 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.
2. Metrics - Insert user feedback into nightly reports and dashboards.
3. 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.
4. 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.
5. 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

Strategy

• 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.

Outcomes

1. Scale to cluster over millions of pieces of feedback.
2. 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
3. Experiment with locale-based feedback to create possible stop-words for multi-language clustering
4. 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

Strategy

• 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.

Outcomes

1. Users will be able to give praise, issues and idea type of feedback on any build of Firefox and Firefox on Mobile.
2. Users will be able view feedback submitted over any channel/build of Firefox and Firefox on Mobile.
3. Mozilla staff and community will be able to retrieve more channel-specific insight

Roadmap

Q1: Extend Input to Major Releases

Q2: Graduate Input into a Platform

Q3: Tighten the Feedback loop

Q4: Expand onto other Mozilla products

Non-Priorities

1. 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.