Page MenuHomePhabricator

Interlanguage selector creates erroneous whitespace on projects that don't have the tagline enabled and use indicators
Open, MediumPublic

Description

If a wiki does not have a tagline (or the user has chosen to hide it) and that page has a protection, FA, GA or some other indicator, the following will be displayed:

Screen Shot 2021-05-06 at 18.03.37.png (620×2 px, 434 KB)

The indicators should be in line with the title, to the right of the new interlanguage selector.

Event Timeline

Srdjan renamed this task from Interlanguage selector creates erronous whitespace on projects that don't have the tagline enabled and use indicators to Interlanguage selector creates erroneous whitespace on projects that don't have the tagline enabled and use indicators.May 5 2021, 7:09 PM
ovasileva triaged this task as Medium priority.May 25 2021, 10:25 AM
ovasileva moved this task from Incoming to Needs Prioritization on the Readers-Web-Backlog board.

This is currently behaving as expected, but I agree that it could use some work. @alexhollender - any thoughts here?

[for clarity/simplicity sake I'm using the terms right and left and assuming a LTR language wiki here — the same points apply, just with right/left reversed, for RTL]

Starting with some context: this was anticipated and discussed in T263511#6579782.

This task seems to propose moving them up so that they are displayed next to the (new) language switcher. To clarify here are some mockups of what I understand @Srdjan's suggestion to be:

The indicators should be in line with the title, to the right of the new interlanguage selector.

DE.jpg (268×1 px, 230 KB)
NL.jpg (268×1 px, 170 KB)
FR.jpg (268×1 px, 169 KB)

One result of this approach would be that the language switcher is not presented in the same location on every page. Instead, the location would be variable depending on the presence of page indicators. I think it's quite important for the language switcher to be presented in the same location on all pages, so I unfortunately I don't think this approach is viable.

The next question might be: what about if we placed them on the left-side of the language switcher, so they were positioned in between the page title and the language switcher? This would result in the language switcher being in the same location on every page (✔). However due to the variable length of page titles, and the variable length of the language switcher (due to different language strings), this would get messy in many situations.

In short, the page indicators need a substantial amount of dedicated space, and shouldn't interfere or distract from more important elements such as the page title and the language switcher. That is, more or less, how I arrived at the conclusion that they should be below the heading underline:

image.png (677×1 px, 71 KB)

From there we return to the awkwardness several people have pointed out. As discussed in T263511 the benefits of keeping article indicators right-aligned are:

  • they appear in a consistent location regardless of the project language
  • they remain at (relatively) the same visual prominence as they currently are

The obvious alternative would be to left-align them in cases where the project had no tagline. However we would then fail on the two pros listed above. For reference that would look (roughly) like this:

image.png (268×1 px, 143 KB)

things get rather subjective here, but I believe that placing page indicators underneath the article title is a significant change in the visual prominence of those elements and should be discussed and/or researched before such a change is made. I also don't think that decision needs to be made as part of this work, as I don't see the awkward gap being a major issue. Another alternative would be for those wikis to add the tagline back, or some other similar element, in order to fill the space.

cc @RHo @Volker_E @Pginer-WMF

I also don't think that decision needs to be made as part of this work, as I don't see the awkward gap being a major issue.

Wikimedians are sensitive to whitespace. It will be a major issue.

I also don't think that decision needs to be made as part of this work, as I don't see the awkward gap being a major issue.

Wikimedians are sensitive to whitespace. It will be a major issue.

right, well hopefully it doesn't become a major issue :) I would suggest that we wait to see what kinds of complaints we hear over the upcoming months, and then focus energy accordingly. There is no simple solution here unfortunately. If it's helpful: we can explain this as a tradeoff for increased usage of language switching, which hopefully people will appreciate as a worthwhile tradeoff.

This task seems to propose moving them up so that they are displayed next to the (new) language switcher.

This place, opposite of page header text, is where indicators were so far and where they nicely suited, and where associated icons and alike also were before indicators were introduced. I'd rather wonder if new language button really needs to go into this already occupied space. I don't know what would be good place for language button, but have you considered tab bar? Something like this:

18lang.png (59×507 px, 3 KB)

we can explain this as a tradeoff for increased usage of language switching, which hopefully people will appreciate as a worthwhile tradeoff.

As someone who translates from a variety of wikis (sometimes from languages not in the "Suggested languages" list), it takes more time to switch now compared to legacy Vector (two clicks vs a single click, and the tiny pop-up dialog with languages not listed alphabetically makes finding them more difficult if you're used to scrolling). Also given that I don't think the vast majority of readers are bi or multilingual anyway, I'm skeptical on whether it could be called a "worthwhile tradeoff". I'm not a fan of creating a regression and then "not seeing it as a major issue" or asking a wiki to re-add redundant elements like the tagline.

If the current implementation can't be changed, I think having the short description on wikis that don't use the tagline would be more useful; essentially integrating this gadget, which could look something like this:

Screen Shot 2021-05-27 at 09.09.32.png (679×2 px, 419 KB)

we can explain this as a tradeoff for increased usage of language switching, which hopefully people will appreciate as a worthwhile tradeoff.

As someone who translates from a variety of wikis (sometimes from languages not in the "Suggested languages" list), it takes more time to switch now compared to legacy Vector (two clicks vs a single click, and the tiny pop-up dialog with languages not listed alphabetically makes finding them more difficult if you're used to scrolling).

When estimating the effort I think we need to estimate the action to scroll and find the list of languages. Also for classic vector there are two versions of the language list:

  • The compact language list shows a short list of suggested languages which will be available as suggested languages directly after open the new selector.
  • The old flat list shows al languages directly but that comes with the effort to finding the language in the middle of a potentially long list without aids for searching (unlike the language selector)

Finally, the original location at the end of a crowded sidebar requires an initial discovery effort too, which may result on not serving the needs of users that need to switch the language because they don't expect the functionality there.

If the current implementation can't be changed, I think having the short description on wikis that don't use the tagline would be more useful; essentially integrating this gadget, which could look something like this:

Screen Shot 2021-05-27 at 09.09.32.png (679×2 px, 419 KB)

Integrating the short description seems an idea worth exploring. On mobile (web and apps) this is displayed around the title area, so it would be consistent. One consideration is that not al the topics have such info available, so a fallback may be needed (option to contributing it, leaving it blank, or something else...).

Just wanted to pitch in with some of the data we've collected so far on the button itself. The new language button has so far been tested qualitatively across a number of different tests - details are available at https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Features/Language_switching#User_testing. So far, the button has been received positively in our prototype testing with editors, as well as a separate user test with reader. We also tested the time required to find the new button versus the old option and saw that the new button was up to 4x quicker to find than the previous version that required scrolling down the page - results are available here. https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Repository/Language_Switching_User_Tests#Test_results.

That said, since this is a big change, there's a few more checks coming up from our side. Mainly, we will begin quantitative testing on a set of pilot wikis that will compare the usage of the old vs new version (details available in T269093: Deploy new language switching location to test wikis and begin A/B test pt 1). Also, for people that switch languages fairly frequently (for translations for example), we are considering adding direct links to their most used languages. These are still early ideas, but there are more details as well as a mockup available here: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Features#Language_switching_2:_One-click_access_to_preferred_languages

Sketch_of_emphasized_language_switching_options_on_a_scrolled_page_for_Desktop_improvement_project.png (704×1 px, 472 KB)

One consideration is that not al the topics have such info available, so a fallback may be needed (option to contributing it, leaving it blank, or something else...).

Here's how that gadget handles it currently:

If it's empty:

Screen Shot 2021-05-28 at 15.22.43.png (488×1 px, 97 KB)
Screen Shot 2021-05-28 at 15.22.48.png (524×1 px, 99 KB)

If it exists:

Screen Shot 2021-05-28 at 15.28.26.png (479×1 px, 94 KB)
Screen Shot 2021-05-28 at 15.28.32.png (513×1 px, 110 KB)

That seems like a decent idea, though obviously the UI would need to be tweaked.

If Wikidata descriptions are to be integrated, it's quite important to be able to add and edit them directly on Wikipedia.

In T282027#7114398, @Srdjan wrote:
Also given that I don't think the vast majority of readers are bi or multilingual anyway, I'm skeptical on whether it could be called a "worthwhile tradeoff".

According to this 2013 academic study published in Trends of Cognitive Science more than half the world's population is bilingual.

It is generally believed that more than half of the world’s population is bilingual [1]. In each of the U.S. [2] and Canada [3], approximately 20% of the population speaks a language at home other than English. These figures are higher in urban areas, rising to about 60% in Los Angeles [4] and 50% in Toronto [3]. In Europe, bilingualism is even more prevalent: In a recent survey, 56% of the population across all European Union countries reported being functionally bilingual, with some countries recording particularly high rates, such as Luxembourg at 99% [5]. Bilinguals, therefore, make up a significant portion of the population. Importantly, accumulating research shows that the development, efficiency, and decline of crucial cognitive abilities are different for bilinguals than for monolinguals. What are these cognitive differences and how does bilingualism lead to these changes?

This 2019 article in the Washington Post suggests the same.

This 2019 report compiled by Eurostat shows similar numbers.

While we don't have data on how many Wikipedia readers are bi, or multi, lingual, we have made a general commitment towards knowledge equity and inclusion (link). I think it is important to keep this commitment in mind as we discuss the tradeoffs here. My interpretation of that commitment as it relates to this discussion is: I think it's important that we welcome any/all newcomers (and existing community members) with a clear and easy way for them to find the language they prefer.

We all are faced with difficult decisions and tradeoffs when updating the interface. Every element is important, but my belief is that some elements/functions are more important than others. If the data we collect in the future (as Olga alluded to here T282027#7118749) continues to show that people are able to discover language switching more easily, and switch languages faster, I firmly believe that added value is greater than the drawback of having some awkward whitespace below the article title. I recognize that this might come across as harsh, or somehow flippant, as you said:

I'm not a fan of creating a regression and then "not seeing it as a major issue" or asking a wiki to re-add redundant elements like the tagline.

I would ask you to assume good faith here, and either trust (or read our research to verify) that we are not taking these decisions lightly. We are similarly bothered by awkward whitespace, but again some elements/functions outweigh others in terms of value and importance to the people using the website.

We also tested the time required to find the new button versus the old option and saw that the new button was up to 4x quicker to find than the previous version that required scrolling down the page - results are available here.

This metric is essentially meaningless. Of course the previous version takes longer to find, you’ve basically outlined yourself why: it is further down the page, so it would take longer no matter what the other design would be. Any design making the list higher would win in such a comparison. It is not a fair test and it cannot be used to prove or conclude anything. (A fairer version would’ve been the one where old language list in sidebar was visible in the first screen in both tested versions.)

The line break and white space is even more evident where other items where added below the absent tagline. Look at http://eu.wikipedia.org/wiki/Lehen_Mundu_Gerra to get an example of how white space is a problem.

irudia.png (597×1 px, 379 KB)