Hi everybody,
Here's an update of what the team has been up to:
*Stats are updated!*
Yesterday we:
- updated www.wikipedia.org stats, - updated the sister portals with the latest version from Meta. - www.wikibooks.org - www.wikinews.org - www.wikiquote.org - www.wikiversity.org - www.wiktionary.org
In order to improve the process Deborah created a recurring task for it T128546 https://phabricator.wikimedia.org/T128546.
It's pretty cool to see what's changed :)
- www.wikipedia.org (https://github.com/wikimedia/wikimedia-portals/commit/864d5ebed066aa3267a17a...) https://github.com/wikimedia/wikimedia-portals/commit/864d5ebed066aa3267a17a5eb97409c69093e03b
- sister portals (https://github.com/wikimedia/wikimedia-portals/commit/2e57bfbd83acce979a25bf...) https://github.com/wikimedia/wikimedia-portals/commit/2e57bfbd83acce979a25bf213dfd9b44310e3ec2
*Deploying the enhanced search box to production*
Phab: https://phabricator.wikimedia.org/T125571
We had a list of improvements to make before pushing to production. It took us longer than expected, specially because the language picker implementation was not 100% production-ready:
- IE8(and lower) users were ignored for the A/B test. - We initially took the decision to not support IE8 for the A/B test in order to save development time (in case the test results show no improvements). - Mobile user experience was not optimal because of the custom dropdown. - We took the decision to figure this out only once we got the test results, to save some development time (in case the test results show no improvements). - The language picker relied on JavaScript and no solution was provided for non-JS users.
We will learn from our first A/B test. The test showed a significant improvement though, and we are now getting ready for a deployment to production. Here's the latest update:
- We changed the custom dropdown, triggered by JavaScript, and replaced it with a native <select> element. - Styling this native <select> element as well as we can (to match what we had in the A/B test), - but it may look a little odd in old browsers (there isn't so much we can do with <select> elements). - Solves mobile user experience issues because the device's native selector will be triggered and will be a lot easier than a custom dropdown. - Solves non-JS traffic (~ 7% https://upload.wikimedia.org/wikipedia/commons/e/e6/Analysis_of_Wikipedia_Portal_Traffic_and_JavaScript_Support.pdf) because it's a native <select> element (no JS required) - minor detail: only the custom arrow is not clickable because we need a little JS hack.
*Status: *The patch made it to code review today. We will release when it's approved.
As of today, here is what you can expect: We have an idea on how to make it even better for old and weird browsers, but we want to move forward with this now :) And the new typeahead is fantastic!!!
*Next A/B test: Use language detection to re-arrange the primary links to suit the user better*
(Primary links = the 10 wiki links in the screenshot above).
Phab: https://phabricator.wikimedia.org/T125472
For the test we read the user's preferred languages (from the browser) and show the corresponding wikis in the most top positions. Let's see if people click on these links more than usual !
Please come to Deborah and us if you have any question :)
*Status:* The patch made it to code review today. We will merge it into its feature branch as soon as it's approved. Then we will review the A/B test setup one more time and schedule a launch date.
We hope to get the new search box in production before we launch the A/B test.
*Improving performance*
Performance matters... it's a huge part of the user experience.
We only talk about it when it's bad, we often forget it when it's good. Performance improvements can definitely increase user engagement.
Take a look at what we've done since November: https://grafana.wikimedia.org/dashboard/db/webpagetest-portals :)
For the Wikipedia.org portal team,
Julien.