Page MenuHomePhabricator

Build language overlay design alternative
Closed, ResolvedPublic8 Story Points

Description

User story
As a multilingual user of Wikipedia mobile web I frequently check articles in other languages. When i use the button "read in other language" I want a better experience of choosing a language. I am highly intended user to switch the language. It would be nice If software can help me pick a language quickly and without much mental overhead.

The Problem
There are two parts to this problem. The language switcher and the experience after the intent of switching a language has been established. Before we fix the first problem, we need to fix the second problem.
The classic funnel example of better experience then more people vs more people then better experience.

For e.g. I would invite my friends over for a house-warming party once I have the necessary things in the house for them to have a good experience.

The Solution
There are two parts to the solution too :) we need to change a small part of functionality and improve the visual design to reduce the "thinking" that a user has to do before tapping on anything.

PART I: The functionality change

While selecting languages, the UI should show 2 buckets of languages.

  1. Preferred languages
  2. All other available languages

Preferred languages is a list of languages preferred by the user.
To populate this list there are two ways

  1. If a user has switched language of an article once
  2. If user has specified any languages to the OS, browser or anything else that we have access to [1]

From the above, we already do the first one viz. if someone selects a language it goes to the top. now it will go to this bucket.
Second one just uses similar technique as desktop to learn more about the user.

The goal is to predict what languages the user speaks and put them above everything else under a bucket called "preferred"

[1] e.g., window.navigator object or potentially in the API response based upon the user's Accept-Language header, although the latter necessarily cannot be cached easily by api.php and the former is much simpler

PART II : The display
The second part of the task is to change how we show list of languages.

Current representation of languages

  • This is a flat list of languages
  • Without hierarchy, it's difficult to scan
  • Missing names of the language in current language

Proposed design

The hierarchical language variants for some languages.

  • The first list item shows the primary name and primary domain of the language
  • The indented list shows the extension of the primary domain. ZH-HANT, ZH-HANS. as we show ZH on top we just need to show the extension (hans, hant) in the children items

  • Two buckets: preferred and all. better visual separation gives purpose of the buckets
  • Better hierarchy of words
  • Language codes (we need these later when we make language switching better in article)
  • The text below the language is the name of the title (not a wikidata description!)

Acceptance criteria

  • It must be possible to compare the "old" modal engagement with the "new" modal engagement. One early signal will include data. One signal will be observation of data arriving from the change implemented in T123932: Instrument mobile web language switching user workflow, which will be rolling out on the train week 1 of sprint 65. The other should be an A/B test in mobile web stable; the A/B test in mobile web stable should be conducted in isolation from any different UX placement of the actual "Read in another language" button, so that it is simple to disentangle cause and effect.
  • languageOverlayVersion value when languageListLoaded value sent is structured-overlay.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jdlrobson edited a custom field.Feb 1 2016, 5:21 PM
bmansurov claimed this task.Feb 1 2016, 8:35 PM
bmansurov moved this task from To Do to Doing on the Reading-Web-Sprint-65-Game of Phones board.
bmansurov added a comment.EditedFeb 2 2016, 12:14 AM

I must admit - whoever wrote these lines is a great poet:

The classic funnel example of better experience then more people vs more people then better experience.

For e.g. I would invite my friends over for a house-warming party once I have the necessary things in the house for them to have a good experience.

^ Great allegory that I don't quite understand.

@bmansurov I wrote those

It means you need to make the experience better before making the entry to that experience prominent. we are planning to make the language switcher prominent ( sticky footer or otherwise) so effect of that will be more people seeing language overlay. we need to fix language overlay first before making language switcher prominent.

(this is one of the reasons, not the only primary reason for doing this task)

does that answer your question?

@Nirzar, thanks, it does. Don't get me wrong - it wasn't that unclear. I just liked the way it was described and wanted to point it out. ;)

@bmansurov no no.. I was very skeptical while writing that example too :)

@Nirzar, do you think we should right align the right-to-left languages?

Nirzar added a comment.Feb 2 2016, 7:21 PM

@bmansurov technical we should because we use the script of the other language to represent it so writing language should also be used. but that will break the layout. Specially when you are scanning the list.

Maybe the same reason we dont do that right now?

I don't know why we don't do that right now. If I was looking for arabic, I think it would be easier if arabic was aligned to the right.

Nirzar added a comment.Feb 2 2016, 7:53 PM

@Jdlrobson that is really helpful

@bmansurov let's not add that as a blocking task for this but track that somehow?

bmansurov added a comment.EditedFeb 3 2016, 12:34 AM

@Nirzar, it's already tracked in the above task.

Questions:

  1. How should I display a variant of a language when it's in the preferred languages section? Should I display its parent too? Or just the variant?
  1. Should filtering filter both the preferred list and the 'all' list?
  1. Could you upload some mock-ups for tablet size devices?
  1. Do all languages also include the preferred languages? Or should those be excluded from the all list?
  1. In the above screenshot, all languages except the one with variants show the language and the article title. In the ZH language and its variants there's only one line (and I suppose that's the title of the article?). If so, don't we have to also show the language name?
bmansurov reassigned this task from bmansurov to Nirzar.EditedFeb 4 2016, 12:37 AM
bmansurov added a subscriber: bmansurov.

@Nirzar, feel free to re-assign the task to me once you get the answers to the above questions. The code is semi-decent at this point.

Nirzar added a comment.EditedFeb 5 2016, 1:09 AM

@bmansurov Your questions made me question the nested design I was proposing. after thinking thoroughly, I realized the nested structure, which explains the parent-child relationship nicely, isn't the best way to represent this because it creates problems you mentioned.

Apologies, but I have to change how the nested languages look and make them look exactly like the other languages. this solves all the problems you have mentioned.

How should I display a variant of a language when it's in the preferred languages section? Should I display its parent too? Or just the variant?

The code will have the parent code. the name will be the variant, refer this for more information

Should filtering filter both the preferred list and the 'all' list?

Yes

Could you upload some mock-ups for tablet size devices?

Here >

Do all languages also include the preferred languages? Or should those be excluded from the all list?

Excluded, one instance of the language in the whole list

In the above screenshot, all languages except the one with variants show the language and the article title. In the ZH language and its variants there's only one line (and I suppose that's the title of the article?). If so, don't we have to also show the language name?

The reference name explains this too.

Again, sorry for not catching this earlier but i am hoping this will reduce some work on making the tree structure in CSS.

Nirzar reassigned this task from Nirzar to bmansurov.Feb 5 2016, 1:09 AM
bmansurov added a comment.EditedFeb 5 2016, 2:52 PM

@Nirzar, I'm trying to extract the colors from the mock-ups, but they don't conform to one of the shades of grey that we use. Should I keep using your colors, or should we pick from the following?

@colorGray1: #111; // darkest
@colorGray2: #222;
@colorGray3: #333;
@colorGray4: #444;
@colorGray5: #555;
@colorGray6: #666;
@colorGray7: #777;
@colorGray8: #888;
@colorGray9: #999;
@colorGray10: #aaa;
@colorGray11: #bbb;
@colorGray12: #ccc;
@colorGray13: #ddd;
@colorGray14: #eee;
@colorGray15: #f9f9f9; // lightest

Also:

  • All other overlays have white background. Wouldn't a grey background look inconsistent?
  • Displaying "4 variants of XYZ" may not be feasible because we'll have to fetch a translation for each set of variants in a native language and it may delay the loading of the overlay. Besides, assume there are 2 variants and one of them is in the preferred list of languages, now we'll have a heading and only one variant in the all list. For these reasons, I think it maybe best to omit that heading and just separate variants from the rest of all languages with a think border like in your initial mock-ups. What do you say?
  • Do we just show a blank space if no results are found? Should there be a text instead?

Change 268036 had a related patch set uploaded (by Bmansurov):
New language overlay

https://gerrit.wikimedia.org/r/268036

bmansurov reassigned this task from bmansurov to Nirzar.Feb 5 2016, 10:58 PM

The patch above is ready for review until we get answer for the above questions from @Nirzar.

Use the following grays

@colorGray14 for background
@colorGray9 for language code box background
@colorGray9 for the article name in different languages. "cat" in above examples

All other overlays have white background. Wouldn't a grey background look inconsistent?

We use grays for base and white for cells to pop out. it wont strike out as very different. this is a subtle difference we want to have in all places we use lists.

Displaying "4 variants of XYZ" may not be feasible because we'll have to fetch a translation for each set of variants in a native language and it may delay the loading of the overlay. Besides, assume there are 2 variants and one of them is in the preferred list of languages, now we'll have a heading and only one variant in the all list. For these reasons, I think it maybe best to omit that heading and just separate variants from the rest of all languages with a think border like in your initial mock-ups. What do you say?

I used google translate on what it actually says in production and it says 4 variants in XYZ. maybe they have already taken care of it?

Do we just show a blank space if no results are found? Should there be a text instead?

isn't the button "read in other language" not present if the article is available in only one language? how will the user arrive at a blank state?

@Nirzar,

I used google translate on what it actually says in production and it says 4 variants in XYZ. maybe they have already taken care of it?

Where in production can I see this?

isn't the button "read in other language" not present if the article is available in only one language? how will the user arrive at a blank state?

Yes, but I mean when searching for a language. When a user starts filtering out languages and no results are found, do we show a blank overlay or some text?

@Nirzar, could you answer the questions above? Also, You can see the current implementation here: http://reading-web-staging.wmflabs.org/wiki/Lang#/languages

Unfortunately, there is only one language in there. I'll need some time to add more. If you want we can do a quick session where I could share my screen with more languages.

Nirzar added a comment.Feb 8 2016, 7:43 PM

Where in production can I see this?

https://zh.m.wikipedia.org/w/index.php?title=%E5%85%AD%E5%9B%9B%E4%BA%8B%E4%BB%B6&mobileaction=toggle_view_mobile#/languages

i used google translate to translate the headers

Yes, but I mean when searching for a language. When a user starts filtering out languages and no results are found, do we show a blank overlay or some text?

Yes, we can show a text in the middle of the blank screen while searching.

Nirzar added a comment.Feb 8 2016, 7:51 PM

Also, You can see the current implementation here: http://reading-web-staging.wmflabs.org/wiki/Lang#/languages

CSS fixes

.language-overlay .site-link-list a {
       padding: 0.75em 1em;
}

.language-overlay .site-link-list a div span {
   font-size:0.9em;
}
.language-overlay .site-link-list a div span:first-child {
   font-weight:bold;
}

.language-overlay .site-link-list a div span {
   letter-spacing:1px;
   padding:0.5em;
   min-width:3.2em;
   margin-right:0.75em;
}
.language-overlay .list-header {
   font-family:sans-serif;
   letter-spacing:1px;
}
.language-overlay input.search {
  background-size:24px 24px;
  background-position:0px 0px;
}

https://zh.m.wikipedia.org/w/index.php?title=%E5%85%AD%E5%9B%9B%E4%BA%8B%E4%BB%B6&mobileaction=toggle_view_mobile#/languages

This is a different situation because it's only used to group all languages. Imagine a scenario where we have 5 languages with 2 variants each. We would have to pull translations for those languages that reads "2 variants". So I think it's best to omit the heading for variants. Just visually separating them from the rest of the languages should be enough for now.

@bmansurov can we have just the title for the parent language as the header?

@Nirzar, sure, and make it clickable right? Also what happens when the parent is in the list of preferred languages? Should the variants still show the parent in the header but this time the header is not clickable?

@bmansurov headers are not clickable. what would the click do? also if the language was selected, it would just appear in the preferred exactly as any other language. without any headers since it already has a preferred header

phuedx added a comment.Feb 9 2016, 1:00 PM

While I was testing 268036, I tested that the "Preferred languages" feature was still functioning. I tapped on of the variants of the language so that they'd be, effectively, disconnected from the "parent" language.

@Nirzar: First and foremost, this is an edge case. I think that the behaviour is correct (see the screenshot above) is correct but I wanted to make sure that you were aware that it might happen.

phuedx added a subscriber: siebrand.

268036 has been -1'd by @siebrand. I'll still be re-reviewing/testing though.

I've added more tests per Sam's suggestion, but I'm waiting for @siebrand's reply. If anyone else feels like reviewing the patch, please go ahead and do so.

@Jhernandez, what's a good date to have this in mobile web beta (prod cluster) for your field research?

Not trying to rush anything here, but do want to factor that in.

I'm not really sure, but we'll be in the field from the 14th to the 25th of feb.

I'll send an email to see when we would have slots to test it and report back.

I've changed the heading case to sentence case per @Jdlrobson's suggestion. The patch is good for review.

The patch is merged but will not show up on beta labs as it is disabled by default. Not sure why we didn't ask to put this into beta but I guess we're doing this next sprint. Thus not sure how best you want to sign off.

Over to you @dr0ptp4kt and @Nirzar

@Jdlrobson @bmansurov yay! let's wait and figure out how PO and design and see the changes? or if there is work needed to see them. i would like to see this on beta because of the number of languages available on wikipedia vs. staging.

Enabling it in beta mode won't take too much effort. We could aim to do so and you'll be able to see the change next Thursday. Alternatively, we could spend some time adding more languages to the staging environment.

@bmansurov i believe you just need to update the interwiki table on the staging environment

The question is in which one of the databases? I'll do so tomorrow.

I've enabled the interwiki role on the staging server. You can now add interlanguage prefixes via Special:Interwiki.

phuedx added a comment.EditedFeb 11 2016, 4:49 AM

I've added the following interlanguage prefixes: zh, zh-classical, and zh-hans; and added interlanguage links to Selenium_language_test_page.

@Nirzar, @dr0ptp4kt: You can see the new language overlay in action here: http://reading-web-staging.wmflabs.org/wiki/Selenium_language_test_page?useformat=mobile

Change 268036 merged by jenkins-bot:
New language overlay

https://gerrit.wikimedia.org/r/268036

@dr0ptp4kt I've talked with the research team and it seems like the best candidates for testing it are the expert interviews on Monday 15th, which we're not going to make it.

If it is deployed to beta labs we can try and test it there, otherwise after it is deployed to en wiki we can try and do some guerrilla testing in some cafes the next week (22nd to 25th).

Send me an email when it is available somewhere and I'll inform the team.

If the user types "classical" or "hans" into the search field, those variants aren't shown in the list. Is that desired?

If "zh" is typed, one sees options as follows:

zh
zh-classical
zh-hans

But if "zh-c" is typed the list becomes empty. Is that desired?

Also, is it desired to have the prefix of "zh-" when in typeahead mode but not have it shown by default when not in typeahead mode? Understood, the section label indicates "N variants for <lang>", was wondering if there's any harm in just having the prefixes for those variants for their rectangular labels anyway.

It seems the parenthetical to the right of the language name, for example in the case of "ES Español" there isn't a "(Spanish)" following it. Is that desired? (I do see a parenthetical for the HANS entry but I think that parenthetical is actually part of the legitimate language name, not the additional affordance, which might say "(Chinese Simplified)").

I think one motivation of the language code labels ("EN", "ES", "ZH", etc.) was for better typeahead. It's unclear to me yet whether by having those labels the obviousness of the search box at the top of the modal will improve. As I just noted in T125127#2018650 the search interaction for the existing "legacy" modal seems pretty paltry at the moment. The users who tap on the modal are those we assume are genuinely interested in tapping through, which is bore out by a nontrivial amount of tap through, so we have supposed that they would be interested in the search capability. Do we want to try to improve the obviousness of the search box being a search box somehow? Or do we want to try this modal as is with the current search box graphical design and see if there's an upswing in search usage anyway? If we go with the latter of sticking with the current graphical design of the search box tappable area, and yet search engagement doesn't improve, I wonder if we'd then want to consider removing the search box altogether, and then also possibly the language code labels (unless they confer some other sort of intangible benefit).

Change 270047 had a related patch set uploaded (by Bmansurov):
Structured language overlay filtering fix

https://gerrit.wikimedia.org/r/270047

bmansurov added a comment.EditedFeb 11 2016, 8:34 PM

I've fixed the search in the above patch. I don't know how to get translations for each language from the API. Does anyone know if that's possible? cc @Jdlrobson, @phuedx?

@Nirzar can you answer the design related questions?

If the user types "classical" or "hans" into the search field, those variants aren't shown in the list. Is that desired?
If "zh" is typed, one sees options as follows:
zh
zh-classical
zh-hans
But if "zh-c" is typed the list becomes empty. Is that desired?

I'm not sure which use case this will solve. These codes are mostly meaningless outside developer circles/people that understand ISO 639-3 codes. We'd need data to know if there was a problem.

Also, is it desired to have the prefix of "zh-" when in typeahead mode but not have it shown by default when not in typeahead mode? Understood, the section label indicates "N variants for <lang>", was wondering if there's any harm in just having the prefixes for those variants for their rectangular labels anyway.
It seems the parenthetical to the right of the language name, for example in the case of "ES Español" there isn't a "(Spanish)" following it. Is that desired? (I do see a parenthetical for the HANS entry but I think that parenthetical is actually part of the legitimate language name, not the additional affordance, which might say "(Chinese Simplified)").

We don't know as we don't have data. I would not block this work until we have that data.
Technically this is also difficult/impossible.

I think one motivation of the language code labels ("EN", "ES", "ZH", etc.) was for better typeahead. It's unclear to me yet whether by having those labels the obviousness of the search box at the top of the modal will improve.

Then we should wait till we have strong data to tell us one way or another.

As I just noted in T125127#2018650 the search interaction for the existing "legacy" modal seems pretty paltry at the moment. The users who tap on the modal are those we assume are genuinely interested in tapping through, which is bore out by a nontrivial amount of tap through, so we have supposed that they would be interested in the search capability. Do we want to try to improve the obviousness of the search box being a search box somehow? Or do we want to try this modal as is with the current search box graphical design and see if there's an upswing in search usage anyway? If we go with the latter of sticking with the current graphical design of the search box tappable area, and yet search engagement doesn't improve, I wonder if we'd then want to consider removing the search box altogether, and then also possibly the language code labels (unless they confer some other sort of intangible benefit).

I've merged @bmansurov's patch and I can see no reason not to sign this off. The original requests in the description have been met.

@bmansurov which one exactly, this seems to have evolved into a complex conversation.

Jdlrobson added a comment.EditedFeb 11 2016, 11:57 PM

May I suggest filing any new bugs as subtasks. As @Nirzar suggests this conversation is now impossible to follow.

https://gerrit.wikimedia.org/r/#/c/270047/ needs a review. It fixes the bug Adam reported.

Change 270047 merged by jenkins-bot:
Structured language overlay filtering fix

https://gerrit.wikimedia.org/r/270047

dr0ptp4kt added a comment.EditedFeb 13 2016, 1:47 AM

The search type ahead looks good. I apologize I didn't see this earlier, but when my language is es-xl I expect that ES will be on preferred langs. @Nirzar can you confirm that's what you'd expect, and @bmansurov if so can you make the root language before the hyphen become a preferred language when the more specific variant isn't present yet the more general one is available?

dr0ptp4kt updated the task description. (Show Details)Feb 13 2016, 2:55 PM

Signed off from design

NOTE: we can improve the root and parent language in future. it's difficult to design for something when you don't understand how people exactly use it. it's good for now but let's keep an eye out for any feedback on that side.
bmansurov closed this task as Resolved.Feb 15 2016, 1:20 PM