Mobile/Evangelism

From MozillaWiki
< Mobile
Revision as of 16:02, 5 January 2012 by Tchung (talk | contribs) (Site Testing)

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 correct mobile content vs. engine-specific mobile content vs. overly-dumbed-down mobile content (feature phone content) vs. desktop content which doesn't degrade nicely
  • 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:

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

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:

  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.

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

  • 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!