Page MenuHomePhabricator

ULS widget is in wrong location on English Wikipedia
Closed, DeclinedPublic

Description

On English Wikipedia (but not on MediaWiki.org or Commons), the ULS widget is displayed next to the article interlanguage links. It is extremely confusing to associate the USER language settings with the ARTICLE languages as these two things have nothing to do with each other. It is also confusing having the same widget displayed in different places on different wikis. The correct place for anything associated with the user is the personal toolbar. The sidebar is for UX associated with the wiki and the article. The widget placement on Commons and MediaWiki.org is the correct placement and should be adopted on the other wikis as well.


Version: unspecified
Severity: normal

Details

Reference
bz50789

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:47 AM
bzimport set Reference to bz50789.
bzimport added a subscriber: Unknown Object (MLST).

Background: [[mw:Universal_Language_Selector/Design#Location_for_the_selector]]

Thanks for your input, Ryan. As mentioned in comment 1, this was considered, and we have come to a different conclusion than you have. At this time, we are not considering to make changes in the ULS trigger position.

Could you explain why you came to that conclusion and why putting the widget in the personal toolbar would not be a good idea? This breaks a long-standing interface convention for all Wikipedia users: user functions go in the personal toolbar and everything else in the sidebar. It is also, as I mentioned, very confusing, as the widget has no relation to the interlanguage links with which they are visually associated.

This is a perfect example of making the interface confusing for 99% of users in order to accommodate a 1% edge case. Sure, if you ask random people to change their interface language, they are more likely to find the option if you put it next to the word 'language'. But for the majority of people on en.wiki who want to use the interlanguage links instead, you've made that interface confusing.

Regardless of where you put the ULS widget, I don't think anyone on the internet is going to intuitively understand the concept of changing their interface language separately from the content language. No other site on the internet does this. Most sites change both simultaneously, which is what the interlanguage links do (unless you've customized your interface on other wikis). On multilanguage wikis like meta and commons, there is obviously a need for this (even if it is confusing). On wikis that don't use the Latin alphabet, there is a need for customizing your input method and fonts. Frankly though, I'm not even sure the ULS interface is needed on English Wikipedia. Relatively few people are going to change the interface language and there is no issue with it being difficult to input English-language content. What do you think of removing the ULS widget from en.wiki entirely, and just relying on the standard preferences?

(In reply to comment #5)

But for the majority of people on en.wiki who want
to use the interlanguage links instead, you've made that interface
confusing.

Why do you think it's more confusing now? The cogwheel distracts them? Or what else?

From a UX perspective I would prefer the changing of UI language be done solely via the user preferences.

As for changing the UI language separately from content language, I'm sorry I don't know enough about the use cases to intelligently comment on that right now.

We tested different locations with users. This is what we learnt:

  1. In general, users don't think in terms of content language and UI language as two separate things. Presenting an explicit selection of UI vs. content at the same level forces a decision on them which is based on technology terms instead of user terms.
  1. The main use case related to language change is to access information in a different language. Thus, if a user is reading an article in English and switches to German he will expect to see content in German (and the UI to be in German, or even be kept in English), but it will be surprising to just see the Ui to change and not the content. So in terms of relevance: Content language change > UI language change.
  1. When we placed the language selector at the personal toolbar, many users were considering it the entry point for language change and expecting the behaviour described in (2). So this position works if it replaces interlanguage links (which brings another set of problems), but it does not work if we provide just UI language change. So for wikis with interlanguage links, creating two separate language-related areas where the most prominent one does not solve the main use case was confusing for users.
  1. When we integrated the cog icon in the current language area, it was clear for users that to access content in a different language they had to look for the language in the language list. Only if they wanted more advanced settings and tools, they feel the need to access the settings icon. The cog allows for further adjustment but does not break user expectations.

The idea of the current approach is to avoid introducing a new language-related area for those wikis for which already one exists, and present the advanced tools in a way that is less prominent than the content selection scenario which is covered by the interlanguage links.

In addition, due to the relevance of languages for consuming and contributing content it was considered to provide tools at hand (instead of hiding them inside preferences) especially if we want to provide them for anonymous users for which the preferences view does not exist.