Accountapprovers, antispam, confirm, emeritus
4,925
edits
Changes
no edit summary
The process goes something like this:
* Gather a list of mobile sites to test (top 1700 worldwide, plus regional lists - Alexa? who has this data?)
* Test several levels deep on each site, and file bugs for any parity problems
* 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)
RolesRequired:
* Web site tester (QA ninjas)
* Communicating with sites (diplomatic, getting-to-yes types)
* 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. (Note: the * The focus is on parity problems, where the stock browser does better than us. It is a non-goal to improve sites which suck equally on all mobile browsers.)
==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 needs to must include the mobile web, and we need to make sure that angle is well represented in our writing.
The Hacks team needs to adopt have a greater regular focus on mobile design and implementation - documenting best practices, pitfalls to avoid, best use of limited resources, etc.
==PR==
==Engineering==
We need to find an engineering base point from which to work. That involves decidingat least the following:
* what 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)
