Firefox/Input/Roadmap/2011: Difference between revisions

From MozillaWiki
< Firefox‎ | Input
Jump to navigation Jump to search
Line 18: Line 18:


=== ...Going Forward ===
=== ...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. As a result, users are restricted to only that medium and those channels to view our data. In order to provide real, dynamic value 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 engine with user feedback'''.
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. As a result, users are restricted to only that medium and those channels to view our data. In order to provide real, dynamic value 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 generated insight'''.


== Priorities ==
== Priorities ==

Revision as of 15:53, 14 April 2011

Firefox-512-noshadow.png Firefox Input Roadmap
Owner: Aakash Desai Updated: 2011-04-14
User feedback has proven to be invaluable to the development of Firefox and Firefox for Mobile in the 4.0 release. 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 types of people: passive and active. The latter are contributors. They’re our SUMO, QA, Marketing, Developer, Creative and Campus Rep 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.

Those stakeholders have not had an opportunity to easily voice their concerns over the development of our product. The Input product succeeded there; it has been able to collect close to 2 Million pieces of feedback over Firefox 4′s development cycle and those pieces of feedback have resulted in numerous feature and compatibility bugs filed, valuable UX insight and 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. As a result, users are restricted to only that medium and those channels to view our data. In order to provide real, dynamic value 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 generated insight.

Priorities

Integrate user feedback into product and community development

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 buy-in 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. 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.
  3. RRRT – Input will offer triagers the option to correlate messages per version within “broken”, “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.
  4. 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 hundreds of millions of pieces of feedback. Actually, we’re already doing this.
  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

Priority Item
P1 Support Firefox and Mobile Firefox Releases
P1 Open our Database to the public
P1 Stand up the Grouperfish clustering service

Q2: Graduate Input into a Platform

Priority Item
P1 Offer feedback submission to all channels/builds of Firefox/Firefox for Mobile
P1 Transition to ElasticSearch
P1 Release Grouperfish 1.0
P1 Add a feature using the Input API into, at least, one of Mozilla's user services (SUMO, AMO, Socorro)

Q3: Strengthen the insight provided by Input

Priority Item
P1 Deploy a "Tell Us More" service after submission
P1 Show "Similar Feedback" compared to the just submitted message
P1 Show trends statistics per search
P2 Show user sentiment per search
P2 ...continue to integrate Input into Mozilla's user services (SUMO, AMO, Socorro)
P2 ...necessary dashboard changes due to Firefox/Mobile channel improvements

Q4: Expand onto other Mozilla products

Priority Item
P1 Support Firefox Home
P1 Support Web Products (SUMO, AMO, Socorro, etc.)
P2 Show a Constructivity Meter during submission
P3 ...continue to integrate Input into Mozilla's user services (SUMO, AMO, Socorro)
P3 ...necessary dashboard changes due to Firefox/Mobile channel improvements

Non-Priorities

  1. Identify users to their 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.