This task can be closed. Remaining work + additional work identified by user research is captured here: T137932
The following is a checklist for completion of the definition of the Epic. Make sure to check these off as you complete each item.
- Success Metrics
- External Dependencies
- Product Plan
- User stories
- User Story Phab Tickets
- Metrics Implementation
- Metrics Phab Tickets
- Delivery Date
This is intended to improve the reading experience of users who speak more than 1 language (almost everybody who didn't learn english as their first-language) and primarily for those users whose primary language has limited content. It is quite common for such a user to want to see if the article in another language has more content or if the can understand the content better in another language. This is particularly important for users whose primary lang
Is this goal a Readership Goal that is committed externally here: https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q3_Goals#Reading
The current language-switching button is buried at the bottom of the article and still gets more clicks than the hamburger menu see mobile report card (table name is 'page-ui-daily').
Our current success metric is to increase language switching by 5% on mobile, but another success metric would be to achieve parity with desktop or Android language switching. We have not established those baselines.
Unknown at this time.
The current best thinking here is to put the language switching in a sticky, floating footer bar that can house other article-level actions. This is being explored in the latest version of the iOS app (unreleased as of 12/18) and this ticket for web: T119658 However, early prototyping and design exploration might prove us wrong.
[WIP] Initial prototype
- Create a sticky footer
- Make it responsive
- Open modal on tapping of the language button
- change the language of article from language modal window
Create a protocol for usability testing
Define success criteria
Do the usability test
At a minimum, this requires that language switching within an article is not limited to the bottom of the article, provided that research does not disprove our hypothesis that the bottom of the article is not the optimal location for language switching.
As a user I want to see what other languages an article is available in without scrolling to the bottom of the article.
This will require:
- Ability to roll feature out to subset of users.
- Ability to measure language switching actions per pageview, session or user (only one is necessary, but pageview is compromised because every language switch generates another pageview..but on another project) on mobile web
- Optional: Ability to measure language switching (per pageview, session, or user) on desktop and android
List estimates below. These do not have to be exact. These are just used to validate proposed timelines and ship dates.
|User Testing||2 weeks|
|Beta Testing and analysis||2 weeks (most testing will be done on small % of users in stable)|
|Rollout to stable to small % of users||2 weeks|
|Rollout to all users||4 weeks|
End of February to 2% of stable users?