Also, did you think of the accessibility issues in your solution? Here I especialy think of people with view disabilities, for who js often mean no way to get the content, while a long list of hyperlinks is manageable.
Le vendredi 19 avril 2013 à 20:19 +0200, Pau Giner a écrit : > Thanks for all the feedback! > > > I'll try to respond below to some of the issues raised: > > > Which is the problem? > > > As it has been mentioned, one of the most effective ways of hiding > something is to surround it in the middle of a long list. This > produces two problems: > * Lack of discoverability. users may be not aware that the > content is available in their language (which goes against our > goal of providing access to knowledge). Speakers of small > languages that access the English Wikipedia because it has > more content, are forced to make an effort each time to check > if each article is also available in their language. > * Problems for multi-lingual exploration. It is hard to switch > between multiple language versions since the users has to look > for his languages each time in the whole list. > > > The fact that some Wikipedias adjust the order of the languages, the > existence of user scripts and an Opera extension to solve the issue, > is an indicator of the existence of such problem. > > > > We support lots of languages (+300) but users are normally interested > in a small (1-8) subset of those. We need to make these subset easily > discoverable for our users, and providing them in the middle of a list > with 200 items is not the best way to do it in my opinion. > > > Possible cultural and value problems > > > As it was commented, the multilingual nature of Wikipedia is a strong > held value. However, currently it is hard to know in how many > languages an article is available since you need to count the links. > With the proposed approach we provide a number which helps to > communicate that. So I think we are not going against that value. > > > I think that concerns about the imposition of languages per region are > not a big issue when the previous user choices and the browser accept > language are considered with more priority than Geo-IP. Users just > need to select their language once and it will be appearing in the > short list the next times. These concerns should be more relevant with > the current situation where some Wikis put some languages on top > regardless user choices (for some work 100% of the time, for others > they fail 100% of the time). > > > > I also don't think that we should prioritise the need to hide > "languages that users somehow dislikes" over making it easy to access > the languages that the user wants. In any case, the former is also not > supported with the current approach. > > > Why to hide? > > > I understand the problems commented when language links were initially > hidden in Vector, since uses were required to make an additional step > to get into the same long list of links we currently have. With the > proposed approach, the extra step is only taken in exceptional cases > (e.g., a user in a foreign country accessing from a public pc), and > this is made only once (not for each language change), and aids such > as search are provided to make it really quick. > > > The reordering alternative has some problems compared with the > proposed approach. For example, when a language does not appear on > top, it is hard to determine whether the current article is not > provided in that language or it is in the middle of the list. In > addition, with reordering, you cannot rely on alphabetical order > (while you can present the short list alphabetically). > > > > > Considering size and quality of the article > > > It can be a factor to consider since communicating that an article has > good versions in other languages is a good thing. But I think it is a > low priority one, since I find hard to imagine a user selecting a > language which she does not understand (otherwise will be already in > the short list) just because the article is of good quality. In any > case, users normally speak 1-8 languages, so even in a relatively > short list there is still room for other criteria. > > > The way to access more > > > We choose the "..." so that the label could work across languages. So > that you can go back to your language if you arrive by accident to a > foreign Wikipedia (or you are an advanced user curious to check if web > fonts were enabled in Javanese wikipedia). However, the visual > execution needs some work still to make it more touch friendly among > other things. > > > Details on the language list UI > > > The interactive prototype was created to communicate the main idea and > most details are still lacking. > > > Thanks for pointing layout and navigation problems. The layout of the > list is one of the aspects that needs more work: currently we group > the languages by script to help the user to recognise their familiar > scripts, and the algorithm also makes some control of orphan/widow > items. That works well for very long lists of languages, but needs > further tuning when the number of elements is reduced. An algorithm > that presents the list optimally for all possible lengths is something > to be done. > > > > > > > Pau > > > -- > Pau Giner > Interaction Designer > Wikimedia Foundation > > > On Thu, Apr 18, 2013 at 6:50 PM, Pau Giner <[email protected]> > wrote: > As multilingual content grows, interlanguage links become > longer on Wikipedia articles. Articles such as "Barak Obama" > or "Sun" have more than 200 links, and that becomes a problem > for users that often switch among several languages. > > > As part of the future plans for the Universal Language > Selector, we were considering to: > * Show only a short list of the relevant languages for > the user based on geo-IP, previous choices and browser > settings of the current user. The language the users > are looking for will be there most of the times. > * Include a "more" option to access the rest of the > languages for which the content exists with an > indicator of the number of languages. > * Provide a list of the rest of the languages that users > can easily scan (grouped by script and region ao that > alphabetical ordering is possible), and search > (allowing users to search a language name in another > language, using ISO codes or even making typos). > I have created a prototype to illustrate the idea. Since this > is not connected to the MediaWiki backend, it lacks the > advanced capabilities commented above but you can get the > idea. > If you are interested in the missing parts, you can check the > flexible search and the list of likely languages ("common > languages" section) on the language selector used > at http://translatewiki.net/ which is connected to MediaWiki > backend. > > > As part of the testing process for the ULS language settings, > I included a task to test also the compact interlanguage > designs. Users seem to understand their use (view recording), > but I wanted to get some feedback for changes affecting such > an important element. > > > Please let me know if you see any possible concern with this > approach. > > > > Thanks > > > > > -- > Pau Giner > Interaction Designer > Wikimedia Foundation > > > > > -- > Pau Giner > Interaction Designer > Wikimedia Foundation > _______________________________________________ > Design mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/design _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
