From MozillaWiki
< Mobile
Revision as of 16:38, 8 December 2011 by Gerv (talk | contribs)

Jump to: navigation, search
Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

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 thing for a Webkit-focussed mobile web.

Here is what a kick-ass, successful Mobile evangelism program would involve:

Site Testing

  • Develop a way to track the testing of these sites, and organize testing sprints to accomplish the testing.
  • Test several levels deep on each site, using baseline (native Fennec?) and comparison browsers (Firefox desktop, stock browser, ...) and file bugs for any parity problems

There's a separate page with some proposals on the mechanics of managing this project.

Problems We Are Looking For

Link here to known problems that we are looking for during the testing and evaluation of the top sites, e.g:

  • Getting mobile content v. desktop content
  • Getting Webkit-specific CSS

We need to continue to have the recently-added feature that allows toggling between mobile and desktop content to help with this kind of testing.

Problems That Have Been Already Found

Current problem lists:

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 to develop some metrics for monitoring progress:

  • number/% of sites where testing is completed
  • number/% of sites were serious parity problem(s) exist
  • number/% of sites where incidental parity problem(s) exist.
  • backlog of engineering bugs not fixed
  • backlog of site bugs not implemented
  • number of sites where we have/haven't established contact

Stats could be broken down to: mobile aware, but not fennec aware vs. not mobile aware at all.


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.

The Hacks team needs to have a regular focus on mobile design and implementation - documenting best practices, pitfalls to avoid, best use of limited resources, etc.


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.


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:

  1. 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.
  2. 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.


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)


  • Other vendors have the same problem, and they have significant resources at their disposal. Can we collaborate with them?
  • 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."

So what are we waiting for? :-) Let's get stuck in!