Engagement/Feature Based Communications/

Moving to Feature-Based Communications and Engagement

• Move to silent updates in product changes the communications and engagement strategy to a feature based model.
• For any questions concerning the information on this wiki, please contact lmesa@mozilla.com

Background

Historically, Firefox communications and engagement with users, developers and press has revolved around release numbers and product updates. Examples of that engagement and communication strategy include campaigns and press cycles with Download Day for Firefox 3.0 and Firefox 4.0.

The move to a new development cycle has made it clear that although it is important to the Firefox userbase to get features at a faster pace, the update process itself is painful. Firefox engineering has consequently been working to implement parts of the “silent update” process for Firefox with Firefox 10 & 11. Firefox 11 or 12 could then consequently be the first “fully silent” experience for the Firefox userbase. This move is great for our users but is a departure from the typical strategies that Engagement teams and contributors have used to communicate with users, developers and press.

Silent Update: Implementation Timeline (Subject to Change)

• November 8, 2011: Firefox 8 release
  • Silent Update: Lessen the display of app update UI
  • Silent Update: Lessen the showing of the what's new page
  • Ensure user accepts add-ons installed by third-party apps
  • Confirm add-ons on upgrade
• December 20, 2011: Firefox 9 release (Last Planned WN Page)
• January 31, 2012: Firefox 10 release(Last “noisy” update)
  • Silent Update: Removal of OS security dialog for Windows *tentative*
    
  • Silent Update: Apply update on shutdown *tentative*
    
  • Silent Update: Add-ons Default to Compatible
• March 6, 2012 : Firefox 11 released. (First fully silent update.)

Silent Updates: What it means

• Users will no longer be informed when a new Firefox desktop update is available, and instead, Firefox will update automatically and silently in the background. (Silent Updates do not effect mobile).
  
•  Versions numbers become almost meaningless for consumers, although a critical tracking feature for developers.
  
• Add-On Compatibility will default to compatible and Firefox users will not need to opt in to the update if there are add-ons that are not compatible, therefore lessening/diminishing add-on update pain.
  
• We will move to feature-based blog announcements as opposed to release based announcements.
  • Instead of blogs happening every 6 weeks because of releases, we craft blog posts around a set of similar/thematic features.
  • This may still mean we do a blog post on Firefox 16 around sharing, but that blog post won't include a run down of all 40 features we added since Firefox 15, but instead will focus on other related features to the product vision of sharing.
  • Will likely effect how Hacks, Developer, Product blogs (add-ons, for example) support/announce features.
• Feature based campaigns as opposed to release based campaigns.
  
  • light weight, general campaigns are not tied to specific feature launches and can happen throughout the year.
• What's New pages will no longer be updated per release, and instead will be reserved for major announcements.
  • Examples include the Mozilla Apps launch, Boot2Gecko Launch, or other major Mozilla project initiatives.
• Many communities rely on WN pages and release based communications to communicate with their members and locales, so will need to find alternate means of regular communication.
• We will be able to use a combination of less obtrusive notifications (door hangers, pull downs) to bring the user's attention to specific updates. (Still TBD)
• The Home Tab will be launched as the alternative to the About:Home page.
  Snippets will be placed here.
  • Engagement might have more real-estate to play with on this page, but still TBD
    

Feature Based Engagement: What's Awesome

User Communication

• Better, more secure experience with Firefox for our users across the board.
• Focused and themed communications that can be easily managed and integrated across all communications channels.
  
  • Highlight specific features that build on the product positioning,vision, themes and Mozilla values instead of having to list everything in a release (can make story feel disjointed).
    
• Advance notice of features with the new development cycle make is significantly easier to coordinate with all contributors around major features, feature based campaigns, product demos and developer programs.
  

Developer Communication

• Opportunity to create strategic programs for developers
• a community-driven caniuse.com project where we can document technologies independently of version, and point to tables indicating which releases support them.
• MDN documentation can be updated to serve developer community.
• Focused Product Demos Program
  

Press Communications

• Create a strategic blog program for feature releases in parallel with developer communications.
• Opportunity to streamline communications channels.
  

Feature Based Engagement: Concerns

These are areas we need to be aware of, and in most cases, will be addressed with blockers.

User Communication

• Loss of the What’s New Page is a major promotional page for campaigns, an the main point of organic growth for our social media, and community communications.
  
• Many communities rely on WN pages and release based communications to communicate with their members and locales, so will need to find alternate means of regular communication.
  
• Mobile releases will not be “silent”. Users will still get an App update in Android, so how do we stay consistent across platforms?
  
• New Native UI will stay on the train model, but will likely be released out of band. It’s also possible that we “skip” a few releases. How do we communicate this effectively without release based blog posts?
  
• Enterprise Working Group will still communicate on a release based cadence.
  

Developer Communication

• Developers will still need a way to to follow releases and to know what features are included in each release. This is particularly important for documentation.
  
• Developers need an easy way to continue to download older versions of Firefox for testing.
  

Press Communication

• Need manage expectations of press coverage of “updates”.
  
• Need to clearly communicate the reasons for the move to silent updates
  
• It's important for tech press to know what is included in each update. We need to keep them informed, even if we aren't doing release blog posts
  
• No in-product notification of move to silent updates. Potential for reporters to write about their own experiences with silent updates through the lens of a user.
  
• Moving around the UAC to get to silent updates could raise security concerns.
  

Feature Based Engagement: Blockers

The bullets below highlight critical issues that block the move to feature based marketing. I've named potential owners who should be responsible for putting together a policy or plan to address the respective blockers together for the end of Q4 2011.

User Communication

• Understanding what new promotional channels will look like and when and how they should be used, while also trying to see if they will be of use to help grow user engagement channels. [LMesa, LForrest, JFinette]
  • Need to work with PMs, UX and sharing plans ASAP
• Clear Product Positioning to inform themes and help discern which features to promote and communicate.[PMMs]
• Clear Value Propositions for all Features that are shared to all with advanced time to create campaigns. [PMMs]
• Clear Brand Strategy to help inform campaigns. [JSlater, KBaird?]
  
• Plan for rallying contributors around themes, campaigns instead of releases [Mary, LMesa, JFinette?]

Developer Communication

• Documentation Policy for MDN [Sheppy and Janet?]
  

Press Communication

• Communications plan for press, contributors and developers[Erica, LMesa, Stormy?]
• New plan for PM, PMM feature/information outreach for contributors and paid staff to have a better understanding of upcoming features in order to better plan campaigns. [PMs & LMesa]
  
• Blogging policy for development channels, releases and developer blogs [Stormy?, Erica J, LMesa]