Mobile/Evangelism: Difference between revisions

Jump to navigation Jump to search

Mobile/Evangelism (view source)

Revision as of 13:11, 1 December 2011

867 bytes removed ,  1 December 2011
no edit summary
No edit summary
Line 1: Line 1:
__NOTOC__
{{draft}}
{{draft}}
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.
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.
Line 4: Line 5:
Here is what a kick-ass, successful Mobile evangelism program would involve:
Here is what a kick-ass, successful Mobile evangelism program would involve:


Roles Required:
== Site Testing ==


* Web site tester (QA ninjas)
* Gather a list of mobile sites to test (top N worldwide, plus regional lists)
* Problem diagnoser and fix suggester (web development ninjas)
** [http://www.google.com/adplanner/static/top1000/ DoubleClick AdPlanner Top 1000]
* Communicating with sites (diplomatic, getting-to-yes types)
** [http://www.time.com/time/specials/packages/completelist/0,29569,2012721,00.html Time's 50 best sites]
** [http://www.pcmag.com/article2/0,2817,2367622,00.asp PC Mag's Top 100 sites]
** Also, [http://www.mobileawesomeness.com/ this site] provides ratings on based on effectiveness on mobile devices
 
* 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


The process goes something like this:
===Problems We Are Looking For===


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


* Gather a list of mobile sites to test (top 1700 worldwide, plus regional lists - Alexa? who has this data?)
* Getting mobile content v. desktop content
** dasher suggests http://www.google.com/adplanner/static/top1000/
* Getting Webkit-specific CSS
** here is another site that provides ratings on based on effectiveness on mobile devices http://www.mobileawesomeness.com/
** Time's 50 best sites http://www.time.com/time/specials/packages/completelist/0,29569,2012721,00.html
** PC Mags Top 100 sites http://www.pcmag.com/article2/0,2817,2367622,00.asp


* Develop a way to track the testing of these sites, and organize testing sprints to accomplish the testing.
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.
* 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


== Evaluation and Site Evangelism ==  
== Evaluation and Site Evangelism ==  
Line 28: Line 30:
* If site needs to change, work out approximately how - the more detail, the better
* 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)
* As appropriate, make contact with site owners to present suggested fix (email webmasters, use social networks and contacts)
== Tracking Progress Though Effective Metrics ==
* Develop some standard metrics for reporting progress
** number/pct. of sites where testing is completed
** number/pct. of sites were serious parity problem(s) exist
*** broken down to mobile aware, but not fennec aware; and not mobile aware.
** number/pct. of sites where incidental parity problem(s) exist.
*** broken down to mobile aware, but not fennec aware; and not mobile aware.
** backlog of engineering bugs not fixed
** backlog of site bugs not implimented
** number of sites where we haven't (and have) established contact


Notes and Thoughts:
Notes and Thoughts:
Line 48: Line 37:
* 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.
* 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.
* 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.
* 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. (not sure I agree with this.  it should also be a goal to promote and track progress on getting the general web moved forward on usability for mobile devices, and in the investigation of each broken site we will stumble along some interesting data about mobile awareness of sites.  maybe we be can refine tracking metrics to show progress on both.  I added this to the metric section above. -- chofmann)


==Kinds of Problems We Are Looking For==
== Tracking Progress Though Effective Metrics ==


Link here to known problems that we are looking for during the testing and evaluation of the top sites.
We need to develop some metrics for monitoring progress:


* Getting Mobile Content v. Desktop Content
* number/% of sites where testing is completed
* Getting webkit specific CSS rules.
* 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


We need to continue to have the recently added features that allows toggling between mobile and desktop content to help with this kind of testing.
Stats could be broken down to: mobile aware, but not fennec aware vs. not mobile aware at all.


==Documentation==
==Documentation==
Line 72: Line 64:
==PR==
==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: [http://devedge-temp.mozilla.org/viewsource/2003/espn-interview/01/index_en.html ESPN], [http://devedge-temp.mozilla.org/viewsource/2002/wired-interview/ Wired News], [http://devedge-temp.mozilla.org/viewsource/2003/media-farm/index_en.html Media Farm]). When the evangelism team comes across a particularly sympathetic site, they should put their name forward to the PR team.
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: [http://devedge-temp.mozilla.org/viewsource/2003/espn-interview/01/index_en.html ESPN], [http://devedge-temp.mozilla.org/viewsource/2002/wired-interview/ Wired News], [http://devedge-temp.mozilla.org/viewsource/2003/media-farm/index_en.html Media Farm]). When the evangelism team comes across a particularly sympathetic site, they should put their name forward to the PR team.


==Tools==
==Tools==
Gerv
Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/374895"

Navigation menu