Mobile/Evangelism/Outreach plan

Goal

This document describes the process to discover, analyze and reach out to Web sites that are not working consistently between Firefox for Android and other mobile browsers.

We want to insure that Firefox for Android users have as good an experience (or better) as when using a competing browser. For Web sites that need to be fixed, we want to push standard solutions that will allow any standards-compliant mobile web browser to display the web site correctly.

We want to do it with responsibility: we want to open the Web for all actors by pushing the use of standards. Except when this is not possible, we shouldn't recommend modifications that would fix the Web site only for Firefox!

Process

The process is divided in three phases:

1. Find problematic web sites: identify which web sites are not working well in Firefox for Android
2. Triage / Analyze the problem: why the site it not working well, and prioritize the severity of the issues the site has in the browser
3. Outreach: reach out to the site to notify them of the problems, provide recommendations on what they can do to fix the issues, and give them information about why it would be good for their site & the web to fix them.

Phase 1: Detecting web sites that have issues in Firefox for Android

This phase consists of testing Web sites and determining if the experience in the Firefox for Android browser is correct or not.

There is a testing guide available that details the steps to take when testing web sites on mobile devices: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_for_Android/Compatibility_Testing

For many regions, you can start with the sites listed on the "Are We Compatible Yet" site: http://people.mozilla.org/~lmandel/arewecompatibleyet and test their compatibility in your locale (if they are localized for your country/region/language).

How & When to Test (some ideas):

• Test for 1/4 hour (or longer). Take a short break to test & find bugs. Be sure to report what you find in Bugzilla.
• Regional competition: Show progress in your locale by comparing to others (25% of the Top-100 pl Web sites tested were compatible vs 12% of the sk ones).
• Organize test days in your city/town/region - get people together to test websites and report issues.

Who can help: anybody with an Android phone -> crowdsourcing

Result: bugs documenting non-working web sites globally.

Open point 1: Is there a way to report issues without a bugzilla account?

Open point 2: Can we have Mozilla Reps in different countries create a Top-100 for their countries (beyond what is in the Are We Compatible Yet list)

Phase 2 : triage / analyse of the problematic

This is the most complex phase as it needs to be carefully done, or the information given to the Web site will be incorrect or incomplete and not everybody have the technical background to do it.

There are two sub-phases

1. reproducing the problem -> anybody can help here (crowdsourcing)
2. categorizing the problems -> This is the critical element and the resource bottleneck

UA: different web sites Android/iPhone/Fx

layout: something doesn't look ok, what.

Behavioral problem: an action doesn't work.

Library problem

Open Point 4: How to make this more efficient?

• Automatic tools to help (detection of Webkit-only properties, detection of different site for different UA, even if it may be imperfect)
• Documentation of the problems and how to check them.

How to follow work in this phase:

• people take a few web sites to analyze: they add [Analysis in progress] and put themselves under Assignee.
• weekly metrics on new [Analysis in progress], new [Analysis done] and list of [Analysis in progress] older than two weeks to see if the assignee need help.

Call for help: assignee should be able to ask more skilled people to help (devs) -> process to establish (?)

Open point 5: process for call for help Open point 6: how to recruit skilled people to help here? This is the bottleneck, at least at the beginning.

Phase 3 : outreach

Once we know what's happening on the Web site (that is when the analysis is complete, that is [Analysis complete] is added in the whiteboard, assignee = nobody, we can work on reaching them.

It is a long going process: most Web sites don't respond, and the greater they are the less response we get. They sometimes silently fix the problem, so even without response we need to periodically re-test them.

The critical point here is to reach the right person inside the organization. Customer care usually just ignore this kinds of requests or answer "You're not a customer."

• Which e-mail address to use:

• Is there a contact address, or form, on the web page. Use this one.
• If not, indicate it in the bug. This will trigger an internal call for help. We may have privileged contacts.

• Once the letter is sent, add [Letter sent] in the whiteboard and a bugzilla entry with the date and eventually address (if public). This will allow to track the reuslts

• Once they respond, we have a privileged address, we should add it to a private list (in case further problem appear). But if the response was private, do not share the address publicly! Indicate in bugzilla that a (non automated) response have been received and what kind of response. Add [Contact established] to the whiteboard.

• If they don't respond after one week, resend the message, they may have skipped, lost it, …

• If no success again, let's change sender: if it was a mozilla address, use a customer to send the message, and vice-versa. Some Web sites are very customer oriented, and other pay attention to big companies contacted them.

• If this doesn't work, we should call for help (Moz Reps channel, escalation), or just wait for a month or two and try again.

Special case for library problem: these are critical cases as they are likely affecting numerous Web sites, and we should use our devengage team to reach them. Also some are open sources, so we should see if we can propose a patch to fix the problem.

• Finally, when the web site is fixed: [Resolved/Fixed or Resolved/Worksforme] and clearing whiteboard.

Events:

• Send to reps once a month a list of Web site that we need to contact, categorized by countries.
• Ask Reps going to events to try to get in touch with people from the company having non-working Web sites, to get new contacts to reach.