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.

See also: Interlanguage links/Implementation comparison.

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. The voting here is a good exercise to help us discuss and understand about the different points of view. By the end of the voting period, we should summarize each of the points raised about each proposal and move on from there, meaning, this is a qualitative, rather than quantitative analysis.

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.
 * Duration: For productivity, we have set a timeframe for feedback collection, start as soon as the designs are up (no later than Tuesday February, 23rd 1:00 UTC) and will end Saturday, February 27th 1:00 UTC).

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 are 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:

Description:
Sticky footers do a great job at increasing the access to actions. We can create an action bar for articles. in this case, changing language and watchlist seems to be good candidates for "doing something no matter where you are in the article"


 * Live prototype:. This can help you check the feature in a live demo.

Known Pros: Known Cons:
 * Access to changing language no matter where you are
 * Add articles to watchlist while you are at the bottom of the article, no need to scroll all the way up
 * Creates a space for future article actions
 * Already tested on native apps
 * Mobile browsers who don't support fixed position or poorly support will not have this feature
 * Sticky footer will take up vertical space on small screens
 * Time to implement is more

Solution 2: Top of the article
Description: We would also like to align article actions into a concise toolbar under the title of the article. These are actions that can be taken on an article.

Three actions
 * Change language
 * Add to watchlist
 * Edit the article

Known Pros: Known Cons:
 * Easy to implement
 * Provides easy access to changing language without scrolling
 * Aligns article actions in a better way than what we have
 * User has to scroll to the top to change the language in the middle of the article
 * Might be coming in the way of casual, monolingual reader [#] (because it pushes start of the article further down the screen??)

Solution 3: Top of the article with different treatment
Description: This is same as Solution 2 but [#] to tackle the one of the Cons from Solution 2, we can try a different treatment.

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.