Reading/Web/Projects/Improve in-article language switching on mobile web

The problem
This is intended to improve the reading experience of users who speak more than 1 language, 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 is more understandable.

Goal Visibility
This is 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').

We have also identified some usability issues with the overlay that appears when the language switcher is opened. It is this latter UX issue that we have started with.

User story 1 : As a user I want to see what other languages an article is available in without scrolling to the bottom of the article.

User story 2: As a user interested in switching the language of the article, I would like to find the language I am interested in as quickly as possible

Success criteria
Our initial goal was: Increase interaction with language switching by 5% on mobile web.

However, simply raising the prominence of the tool could do this simply by showing the tool to so many more users who might click out of curiosity. The revised goal is to "increase language switching (clicking on button and then selecting a language) by 5% on mobile web,without dropping the conversion rate (# of language switches/ #clicks on tool) to below 40%. "

Logic: This should filter out the impacts of simply raising the profile of the tool, based on the assumption that uninterested users will not actually select a language and switch wikis. We want to protects against simply driving more people into the tool and artificially creating higher engagement at the expense of bothering all the people who click, but are not interested. We do expect that more people will open the tool and then exit out. This will lower the 'conversion rate' (# of language switches/ #clicks on tool), but if it stays above 40% AND raises the overall number of language switches, we feel that this tradeoff is appropriate. The current conversion rate is ~60%, so this will mean that we are willing to accept 50% higher rate of people clicking on the tool and not using it, in exchange for 5% higher rate of language switches. This sounds like a bad tradeoff in %'s, but the cost of an extra click, is much lower than the benefit of discovering and reading a version of the article that is better suited to the reader.

Overall feedback
This task is being tracked on Phabricator and we'd love to hear your thoughts.

Help us choose the solution
We are making strides to get community feedback earlier and earlier in the process. We are excited to be asking for your advice at the solution stage, before we start building, and are really excited to see how this works.

The user story we are trying to solve for is User Story 1 from above: As a user I want to see what other languages an article is available in without scrolling to the bottom of the article.

Below, 3 possible solutions developed by our designers are going to be shown. Under each one, please vote with an optional explanation of why you prefer or dislike that treatment over the others. Voting options:

The feedback period can start as soon as the designs are up (no later than Tuesday Feburary, 23rd 1:00 UTC) and will end Saturday, February 25th 1:00 UTC).

Description:
[image]

Known Pros:

Known Cons:

Solution 2: Under the header (reword)
Description:

[image]

Known Pros:

Known Cons:

Description:
[image]

Known Pros:

Known Cons:

Pre-implementation analysis
Refer to the following for some pre-implementation analysis.

T125127 [Release] Confirm language overlay sampling on production working as expected

On 12-February-2016 before changes to the language switcher modal or introduction of a new button placement, the data on the stable channel suggested that globally the "Read in another language" button was tapped about 1.3% of the time when there was an impression of it. This was heavily influenced by enwiki traffic, where the preponderance of traffic existed at the time. A few examples where the button impression sample size exceeded the magical 30 number: On arwiki tapthrough was about 2.5%, hewiki it was about 3.1%, jawiki 0.5%, and eswiki about 0.8%. This was based on the following queries.