Mobile Web Evangelism

Ten years ago, Netscape and Mozilla together put together a massive technical evangelism program to persuade an IE-focussed web to consider Gecko and other rendering engines. Today, we need the same type of program for the Webkit-focussed mobile web.

Goal

The high level goal is to move Web producers (sites, tools, frameworks, etc.) from a Webkit centric approach to an open approach that works with non Webkit based browsers. This evangelism effort will specifically focus on Firefox for Android and Firefox OS.

Scope

sites with mobile versions

tools and frameworks that are included in the development and production of mobile sites

Out of scope

partners with whom Mozilla is already engaged, for ex. companies developing apps for the Firefox Marketplace

User Testing

We need something like the "Report a Broken Website" tool which used to be in Firefox. It could be that Input is that thing, if it can be asked for broken website reports specifically from Mobile Firefox. However, currently, volumes of Input data from Mobile Firefox are pretty low, and that may be to do with access points and workflow - the only access point is XUL Fennec a "Give Feedback" button on the start page, which is not very mentally connected with a problem on a particular site. And the "include your last visited site" option is not auto-populated, so it's very unlikely that a user would type in a full long URL there from memory! I can't find an access point for Input in Native Fennec at all.

A "Report Broken Web Site" menu item on the "Site Options" list, either in all versions of Firefox or in all of them up to Beta, might well get us more data. (Site Options doesn't yet seem to exist on Native Feenec, although one would assume something Larry-like will appear before too long.)

Evaluation and Site Evangelism

Triage and assign to evangelism (site owner needs to change) or engineering (we need to change)

If site needs to change, work out approximately how - the more detail, the better

As appropriate, make contact with site owners to present suggested fix (email webmasters, use social networks and contacts)

Notes and Thoughts:

We would use Bugzilla to triage and filter bugs. It might help to have a shared spreadsheet of the sites to test so people could "claim" a site.

We could do regional testing sprints at local events.

Today, frameworks are used much more than they used to be, so a high priority will be making sure JS frameworks and server-side libraries are all doing the right thing.

We need an army of people doing this. One way to find them might be to ramp up community giving for mobile devices still further.

Tracking Progress Though Effective Metrics

We need a tool for tracking progress of the testing, engineering, and evangelism efforts. The tool should make it clear what actions are required to make a site compatible. The tool will capture the following bits of information.

List of the sites we are consistently testing against. (About 1700?)
- it would be useful to be able to categorize the sites (alexa, phonegap, etc.)

For each of those sites:

when the site was last evaluated

who or what tool did the evaluation

which browser where used in the evaluation

overall evaluation of the site. e.g. site is working, minor visual problems, major display problems, interaction problems, not getting right content

for bonus marks allow filtering of table based on site categories, issue type

Sample table showing rollup

Site Category

Compatible

Minor Issue

Major Issue

Total

Alexa

25

26

27

78

PhoneGap

5

6

7

18

Each of the numbers should be a link that when clicked drills into the details for that category. For example, clicking on 26 will take me to a page that shows the list of apps that have minor issues. This page should then detail all of the minor issues for a specific app such as UA, -webkit, performance, etc.

Note that to begin with we could just roll minor and major issues together. We can separate these later if we determine some criteria.

Note that all of the links may go to the same page. We should provide a way to identify the apps that fit into each bucket within that page - show/hide.

Sample table showing issues

App

UA

-webkit

performance

other

App1

No

No

No

No

App2

No

Yes

Yes

No

App3

Yes

No

No

No

Documentation

MDN needs to become the go-to destination for HTML mobile site development, just as it aims to be on the desktop, with information about all browsers. We particularly need authoritative articles on:

How to properly detect Desktop vs. Tablet vs. Mobile devices

How to design a web site to support a Mobile or Tablet device

But also, our browser compatibility information must include the mobile web, and we need to make sure that angle is well represented in our writing.

Developer Evangelism

Promote cross-browser development to mobile web developers. One part is to make the case that Webkit is no longer completely ubiquitous, and that Firefox Mobile and Opera will continue to grow in popularity on Android. The other part is to encourage use of mobile-specific cross-browser knowledge, techniques and frameworks.

Some action items:

Blog on hacks about how to create a simple mobile theme using a framework like jQuery mobile that works well on all mobile browsers

Do a 'list' post on the mobile web dev frameworks available that do work well cross-browser

Create a slide deck Mozillians can use to give talks at mobile events about mobile web development

Create a list of mobile / web dev events the aforementioned talks could be given at

Recruit Mozillians to give the talk at an event they are interested in attending

PR

In the original Gecko compatibility push several years ago, we got some good press from major sites which had made the transition to cross-browser development, and the wins this gave them. We need to find similar example sites for the current push. (Interviews from that period: ESPN, Wired News, Media Farm). When the evangelism team comes across a particularly sympathetic site, they should put their name forward to the PR team.

Tools

Site testers need suitable tools. Venkman was built, in part, because some Netscape testers were having to use Visual Interdev from Microsoft to debug sites. We are in a much better place now than we were then, what with Firebug etc., but if the testers find they need extra tools, we need to build them.

In particular, we could do with:

an extension which makes Desktop Firefox behave as much like Mobile as possible (user agent, rendering changes, viewport, multitouch simulator). That way, we can leverage all sorts of existing desktop tools and large screens to debug mobile websites. And site authors will love it as well. (We leverage the fact that Gecko on mobile is the full web, same as the desktop, not some cut-down version.) Possible base addons: 1, 2, 3, 4.

an add-on which automatically detected certain common types of error (e.g. use of -webkit- CSS, use of constructs we don't yet support). This would save diagnosers a lot of time.

Engineering

We need to find an engineering base point from which to work. That involves deciding at least the following:

What to do about the User Agent string in the short term (suggestion: remove Fennec/<ver> across the board, add "Mobile" for mobile version but not tablet)

Whether and what -webkit- CSS to support (suggestion: get data on prevalence, but perhaps we could start by supporting their syntax for anything that we already support un-prefixed, as a backwards-compatibility measure)

Allies

Can we get influential web development blogs and sites to point to and recommend our resources?

One of the people involved in the original Netscape Tech Evangelism program said:

"Tech Evangelism was a thankless, never-ending task that was repetitive, intellectually draining, and a technical and career dead-end. The good things were that we had a great team and actually did have a positive effect and laid the groundwork for Firefox's success."