- 1.2 Overall Percentages
- 1.3 Browsers: What is the default browser on android?
- 1.4 Distinction between people who *can't* use js vs. people who choose to turn it off
- 1.5 Where does that lead us as far as features?
- 1.6 Has this been publicly announced yet?
- 1.7 Kudos
- 1.8 Follow-ups:
Complete Analysis File here - which was the basis of the following meeting notes
- 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
- 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
- Is that typical?
Browsers: What is the default browser on android?
- Nexus tend to default to chrome; others tend to default to Android browser
- "Windows Phone market share is unsustainable" --Microsoft boss
Do these numbers align with the portal getting a few percent of total traffic?
- Mikhail will review
Distinction between people who *can't* use js vs. people who choose to turn it off
- 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?
- 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?
- 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
- 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?
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)