Evangelism/WebsiteCompatibilityInternational

International Web Site Compatibility and Tech Evangelism

Goal

To improve Firefox website compatibility and the use of open standards outside of the US and Europe.

Strategy

Take the data that's being collected in reporter and use it as a lever to improve website compatibility for Firefox and open standards-based development. Invite local volunteers to use reports for their countries as a way to help websites in those countries improve compatibility. Give them the tools to be able to work together on these problems. Inform our localization contacts of this as a resource and offer them help in building communities around testing and compatibility.

Overall Plan

Stage One

• Open up communications for the Evangelism team. Start using the external mailing list on a regular basis including posting plans such as this one. Have an open irc channel for people who want to join up with us (#devrel.)
• Talk with Ken to identify key data elements, output and key metrics that can help us drive change.
• Scope out changes to reporter to support per-country information. (Turns out reporter already records locale information.)
• Scope out changes to Firefox to support voluntary per-country information to improve fidelity.
• Scope out changes to support geoip support so we can get country information.

Stage Two

• Look at the current reporter database to see if there are any changes required to improve scaling with today's data
• Set up a dashboard of reports that include:
  • Number of daily reports (total)
  • Number of daily reports (per-browser)
  • Per-country reports (total)
  • Per-country reports vs. local market share
  • Top 10 sites per country (zeitgeist-style)
• Expose this information to the public to help drive awareness and value of the data.

Stage Three

• From first set of data and scoping from stage one, execute on changes to Firefox to improve data fidelity.
• Involve support in this process to see if there are things that can improve end user support.

Stage Four

• Start inviting localizers to start listing places that they know about.
• Set up a wiki place for this stuff to live on developer.mozilla.org including per-country pages.
• Look at setting up per-country mailing lists for evangelism or ways we can manage that through the wiki. (What does localization do?)
• Identify leads in every country to lead efforts.
• Identify and localize docs required to launch a larger effort in identified countries.
• Identify a set of docs that local people can use to describe tech evangelism issues.

Stage Five

• From local communities see if there are "expert tools" (add-ons) that we can create that will allow those communities to do focused testing.

Stage Six

• Look at outreach through PR and Marketing in various countries once we have data on particular countries and a local community to handle questions, community development and press.

Metrics

How many leaders we have in various countries and if they are able to run an effective program for local website compatibility?

This is more about local leadership than anything else. Are we giving them good materials? Are we giving them good data they can work against?

Number of compatibility problems reported per-country?

We can compare reporting information with top-site information on a per country basis to determine how deep into various countries we're getting and how compatible we are with top content in any particular geography.

Market share results?

Does increased compatibility turn into increased market share in a particular market? Does building a local team to handle compatibility also drive awareness, PR and market share as a result of word of mouth work?

Does this give us more tools for end-user support around the world?

It turns out that we can use this data to help end users solve support problems at both an aggregate level but also at a local "I'm having problems with this website" level. We also might be able to use this data directly in Firefox to display reported problems to users with a particular site if and when they use the broken site reporter tool.

WebDev Work Items

• Schema analysis to support l10n
  • The data is currently storing locale information
  • Would be good to gather geoip information since locale doesn't reflect country
  • Not sure if the description is unicode-safe
• Rewriting reporter templates to support gettext in static files
• Schema changes if needed, including modifying service and front-end to work with new schema
• Database optimization and performance tuning as needed
• Front-end scaling (yslow scores) and visual refresh
• Load testing, QA, and Unit Tests

Firefox Work Items

• Iterate to see when people are using Report Broken Website when they shouldn't be or what it's teaching us about how people are using the browser.
• Work with metrics, webdev + evangelism to see if the form in the browser should be updated.
• Take part in metrics design to understand if changes are helping users or not.