Wikipedia Portal and JavaScript Usage - review meeting notes

From mediawiki.org

Meeting to review JavaScript Usage results held on 2016-02-11[edit]

Complete Analysis File here - which was the basis of the following meeting notes

Measure download of the wordmark image ("WIKIPEDIA") vs. the JavaScript[edit]

  • Some browsers appear to have images disabled but javascript allowed
  • Maybe screenreader software would get the js but not images
  • Those users would not get images in the results dropdown either
  • UK for example had more js requests than wordmark

Overall Percentages[edit]

  • 93% is higher than Deb was expecting, so that's good
  • 45% of traffic was from US; next was UK at 8%
    • Is that typical?
      • It matches the portal dashboard numbers
      • We don't have a way to compare it to non-portal traffic

Browsers: What is the default browser on android?[edit]

Do these numbers align with the portal getting a few percent of total traffic?

  • Mikhail will review

Big takeaway:

  • Lots of people don't have javascript

Distinction between people who *can't* use js vs. people who choose to turn it off[edit]

  • KS: People who have turned it off might expect and/or deserve a less awesome experience
  • Older iOS browsers have to use a very slow js engine
    • Poor experience might drive someone to disable js
  • Handy site: http://caniuse.com/ http://caniuse.com/#cats=JS%20API
  • Could we identify traffic coming from browsers that simply don't support js?
  • Obviously we don't want anything to break badly without js
    • We can't clearly distinguish between people who choose to turn it off vs. had to turn it off
  • We know that <1% of traffic is from browsers that literally can't support js
  • Android 4, Chrome Mobile 30, and Opera Mini 7 were least likely to have js enabled
  • Bandwidth limitations may inspire people to disable js

If someone has both images and js disabled, they are not in this survey at all

  • But bots would fall into that category
  • People might disable both in very low-bandwitdh situations

Where does that lead us as far as features?[edit]

  • Can continue moving forward with our existing mock-ups
  • When we do A/B testing, we should monitor how many people are seeing the js
  • Likewise, when we go to production, our dashboards need to reflect that
  • We don't want to make non-js experience worse, just because we are improving the UX with js
  • "js should not be required for searching"

JS support dictates who gets tracked by event logging

  • This shows that 93% of population is being reflected in event logs
  • However, that varies by country, so certain countries are under-represented in EL

Has this been publicly announced yet?[edit]

  • No. We wanted to have this discussion, and allow Mikhail to tie up any loose ends
  • Should we wait for Oliver to get back and review?
    • Probably should wait for Oliver
    • And by then, we'll have another week of data, whcih could affect resutls (presumably in small ways)
  • Let's get it out as soon as it is ready
  • For anything we are going to push to production, we should clearly specify the non-js experience

Kudos[edit]

  • Great job on the report, Mikhail!
  • It's good that we have tangible numbers rather than making guesses
  • The map with US traffic excluded is interesting
  • At end of report, could we have a comprehensive list of browsers?
    • On dashboard, all browsers will be listed without filtering
    • Mikhail will look into possibly adding an appendix to the report
  • Could we segregate results by desktop vs. mobile?

Follow-ups:[edit]

Would be interesting to compare these traffic patterns compared to wikipedia traffic

  • Maybe they never make it from the portal into the main sites
  • Reading is already tracking similar data for the main sites, so we can coordinate with them
  • Deb will follow up with Jan and Oliver to be sure they see the notes
  • Deb will arrange to share results with Reading (with help from Mikhail)