Personal tools

Mobile/Evangelism

From MozillaWiki

< Mobile
Revision as of 06:33, 21 August 2013 by Karlcow (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

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
    • changes to the Gecko platform (subject of another project)

Projects

Mobile Web Compatibility

The focus of Mobile Web Compatibility is to work with companies and individuals to make existing mobile content functional on non Webkit based browsers, specifically Firefox for Android and FirefoxOS. It is part of the wider Web Compatibility effort.

Developer Evangelism

To promote best practices to site developers and ensure that the tools and frameworks they use support non Webkit based browsers, specifically Firefox for Android and Firefox OS.

PR

This project has not yet been scoped. Ideas include a compatibility pr push and case studies for changing a site to function with non Webkit based browsers.

Documentation

To create/update MDN documentation for mobile development best practices and mobile specific topics.

Note: need to revisit this project to ensure doc links are up-to-date

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.

User Agent

CSS

Tools

To create tools to assist with evangelism efforts.

Communication

Communication Type Mechanism Audience
Announcements dev-platform and dev-planning lists all
General discussion dev-platform list devs
Meetings meeting time
  • Dial-in: conference# conf number
    • US/California/Mountain View: +1 650 903 0800, x92 Conf# conf number
    • US/California/San Francisco: +1 415 762 5700, x92 Conf# conf number
    • US/Oregon/Portland: +1 971 544 8000, x92 Conf# conf number
    • CA/Vancouver: +1 778 785 1540, x92 Conf# conf number
    • CA/Toronto: +1 416 848 3114, x92 Conf# conf number
    • UK/London: +44 (0)207 855 3000, x92 Conf# conf number
    • FR/Paris: +33 1 44 79 34 80, x92 Conf# conf number
    • US/Toll-free: +1 800 707 2533, (pin 369) Conf# conf number
  • Vidyo: video room
  • IRC: #ircchannel
  • Agenda:
all
Meeting summaries this wiki all

Press & Blog Posts

Minutes and Progress Reports

Minutes and progress reports are tracked on the Mobile Web Compatibility wiki page

People

Project Champion
Program Management Lawrence Mandel
Web Compatibility Analysis and Contacts Karl Dubost, Hallvord R. Steen
Product Chris Lee (B2G), Karen Rudnitski (Mobile browser)
Incoming Bug Triage Jason Smith, Aaron Train
QA Tony Chung, Jason Smith, Aaron Train
Market Strategy John Jensen
Dev Engagement Jean-Yves Perrier, Ali Spivak

Milestones/Iterations/Tasks

high level milestones can be included in this page. more complex milestones and tracking information (typically bug lists) should be included on a milestone specific tracking page

References

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.

Testing Results 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 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
    • break site problems down by category: UA sniffing (wrong site served), visual problems (-webkit or general layout issues), performance issues (probably layout), interaction (touch or other functionality)
  • links to bugs found in the testing
    • let's tag all of the bugs so that we can easily query for them. we can use site-compatibility, top-apps, something else?
  • who has the next action on the site (QA, Evangelism, Engineering)
    • there may be multiple next action if we need to follow up on UA and fix a layout issue
  • do we have a contact at the site?
    • who has the contact, or is in contact with the site.

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.

Wishlist:

  • automated tool to perform regression testing on a regular schedule (weekly)
  • table that displays sites and issues. columns including: site name/URL, UA identified correctly (yes/no), layout correct (yes, no + reason -webkit, performance, other), functional interaction (yes/no), open bugs
    • 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.

Current Docs

User Agent

CSS

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!

Meetings

Thurs. 9am PT
US/International: +1 650 903 0800 x92
US toll free: +1 800 707 2533 (pin 369)
Canada: +1 416 848 3114 x92
Dial-in: conference# 95346
Vidyo: PB&J
IRC: #planning

2012