Evangelism/WebsiteCompatibilityInternational: Difference between revisions

← Older edit

Evangelism/WebsiteCompatibilityInternational (view source)

Revision as of 21:24, 2 February 2021

3,539 bytes added , 2 February 2021

adding category

Karlcow

Confirmed users

1,567

edits

@@ Line 36: / Line 36: @@
 * <strike>Talk with Ken to identify key data elements, output and key metrics that can help us drive change.</strike>
 * <strike>Scope out changes to reporter to support per-country information.</strike> (Turns out reporter already records locale information.)
+Design:
+* <strike>First iteration of wireframes for initial work.</strike> [http://people.mozilla.com/~nlee/reporter/wireframes/index.html Wireframes]
+Data Changes:
 * Scope out changes to Firefox to support <i>voluntary</i> per-country information to improve fidelity.
 * Scope out changes to support geoip support so we can get country information.
+* Figured out possible changes to support the herdict folks + open data.
 == Stage Two ==
 * Look at the current reporter database to see if there are any changes required to improve scaling with today's data
 * Set up a dashboard of reports that include:
 ** Number of daily reports (total)
 ** Number of daily reports (per-browser)
-** Per-country reports (total)
-** Per-country reports vs. local market share
+* Set up a search box that returns the most recent reports for that domain.  That result should also be available as an RSS feed.
-** Top 10 sites per country (zeitgeist-style)
 * Expose this information to the public to help drive awareness and value of the data.
@@ Line 54: / Line 63: @@
 * From first set of data and scoping from stage one, execute on changes to Firefox to improve data fidelity.
 * Involve support in this process to see if there are things that can improve end user support.
+* Set up a dashboard of reports that include:
+** Per-country reports (total)
+** Per-country reports vs. local market share
+** Top 10 sites per country (zeitgeist-style)
 == Stage Four ==
@@ Line 127: / Line 141: @@
 * Allow web sites to get an RSS feed for reports about their site.  Get them involved directly.
 ** Also could do something like "live feed for top 100 sites in the US" for testing team and RRRT
+* Include information based on network errors: https://wiki.mozilla.org/Firefox3.1/Sprints/Network_Error_Pages
 = Feedback =
@@ Line 132: / Line 147: @@
 *  Stage 4 asks to reach out to localizers.  Consider expanding this to all constituents relevant in local markets.  This includes localizers, campus reps, fans of Firefox, conference organizers, known web developer or other industry contacts, government contacts, etc. (sethb)
 ** Would love help on figuring out how to do these two.  I would like it, too, assuming we're committed to doing this but I don't have a sense of how to do it.  Looking for advice and help. (blizzard)
+*** Seems to me that we could also reach out to the SUMO community and have local contributors write support articles for the top ranked local websites with compatibility problems. (djst)
 *  Consider a tool a bit more dynamic than a wiki to capture websites that need evangelizing.  Perhaps a simple web app with a database collecting information and then a great way to display it.  Would this be hard?  Don't know... (sethb)
 ** The reporter site can do this and won't be a wiki.  It's entirely data driven.  Here's an example of a report for www.google.com for one day: http://tinyurl.com/c3rz4s
@@ Line 139: / Line 155: @@
 * As for type of the problem, in Japan (and I believe in China, Korea etc too) [http://en.wikipedia.org/wiki/Mojibake mojibake] (garbage text) is the most famous broken case (caused by lack or miss of charset in the content type header). I thinks it's nice to add mojibake in the type list in the reporter (at least for multibyte locales). (dynamis)
 * Some problems are caused by addons and reporter should also include installed addons list (not only build config). (dynamis)
+** I was going to add this to the list too; on SUMO we get a lot of suppor issues of sites not working as a direct result of an add-on (e.g. AdBlock). I'm concerned that a lot of the people that use the Site Reporter tool in Firefox confuse it with a way to get support. (djst)
+** Do we really want end-users to report broken websites? Ideally, everyone that reports a broken website should always try with another browser ''and'' trying with Firefox running in Safe Mode (sans add-ons) to ensure that the problem is indeed caused by incompatibilities and not other support issues. (djst)
 * I think volunteer may use Greasemonkey to test, verify and develop code to fix a listed broken page. This code needs to be uploaded to our server database. A mechanism shall be established at back-end to review and verify his code. Meanwhile, we develop an add-on, shipping with Firefox, whenever user open an incompatible page, this add-on will grab the code from server, and fix it. A question is that what a kind of mechanism could ensure this program sustainable? for example, one fixed some pages in CNN.com, a few days later, CNN changed their pages ... (jguo)
 ** Jack, please see the TouchUpWeb project that was co-produced by Mozilla Japan (link below) as this is what was done in Japan. (gen)
@@ Line 148: / Line 166: @@
 *** [http://www.ipa.go.jp/software/open/ossc/download/Web_Recommendations_Summary_En.pdf Recommendations (Summary)]
 *** [http://www.ipa.go.jp/software/open/ossc/download/Web_Recommendations_En.pdf Recommendations]
+** Gen's post on compatibility: http://blog.mozilla.com/gen/2007/11/08/browser-and-web-content-compatibility-in-asia/
+* The goal says to "improve Firefox website compatibility and the use of open standards outside of the US and Europe" -- does that exclude Europe? There are still website compatibility problems in Sweden. (djst)
+** No, no exclusion.  But we have a larger problem outside of the US and Europe so that's where it will be most effective. (blizzard)
+* In the dashboard in Stage 2, per-country is mentioned. Does that mean "issue reported from a user in country X" or "issue reported on a website hosted in country X"? The latter seems more relevant if we want to form local teams of evangelism experts that can reach out to website owners. (djst)
+** We only have data from the users and I imagine there's a rough correlation from users to where web sites are hosted.  I suspect the data will still be very actionable. (blizzard)
+* Having per-country lists of problematic websites (cross-run with the list of the most popular websites of that locale) would be a very effective way of proactively getting support articles written, possible by the same team of people that test these websites. (djst)
+** Yep - that's in the list here.  We'll need data from somewhere else to cross-match, but if we have country data it will be pretty useful to make things actionable. (blizzard)
+* This all looks good but I think we're perhaps missing an opportunity to use our mozilla.org/com traffic to really drive the message directly to broken sites. What about a more highly visible "wall of shame" for these broken sites? One could imagine a tool not unlike the beginning of spreadfirefox where we identify target broken sites ask contributors to help us find webmaster emails and perhaps even more aggressive than that by adding a "email the site and tell them to support standards" (localized) form once we do have an email address. The form email could have stock text that included advertising for the "RSS feed for your site in reporter occurrences" and links to the most common problem types and their solutions (I think the old devedge had some list of documents for common issues.) ( Asa)
+[[Category:Web Compatibility]]