This task can be closed. Remaining work + additional work identified by user research is captured here: T137932
Definition Progress
The following is a checklist for completion of the definition of the Epic. Make sure to check these off as you complete each item.
- Summary
- Rationale
- Success Metrics
- External Dependencies
- Unknowns
- Product Plan
- Prototyping
- MVP
- User stories
- User Story Phab Tickets
- Metrics Implementation
- Metrics Phab Tickets
- Estimates
- Delivery Date
Summary
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
Goal Visibility
Is this goal a Readership Goal that is committed externally here: https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q3_Goals#Reading
Rationale
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').
Success Metrics
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.
External Dependencies
Unknown at this time.
Unknowns
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.
Product Plan
Prototyping
[WIP] Initial prototype
http://nirzar.github.io/prototypes/mobile-web/sticky/index.html
- Create a sticky footer
- Make it responsive
- Open modal on tapping of the language button
- change the language of article from language modal window
Usability testing
-
Create a protocol for usability testing -
Define success criteria -
Do the usability test
MVP
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.
User Stories
As a user I want to see what other languages an article is available in without scrolling to the bottom of the article.
Metrics Implementation
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
Timeline Estimate
List estimates below. These do not have to be exact. These are just used to validate proposed timelines and ship dates.
| Task | Estimate |
|---|---|
| Prototyping | 0 weeks |
| User Testing | 2 weeks |
| Mockups | 2 weeks |
| Development | 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 |
Delivery Estimate
End of February to 2% of stable users?