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