Also, did you think of the accessibility issues in your solution?
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!> * Lack of discoverability. users may be not aware that the
>
>
> 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:
> content is available in their language (which goes against our> * Problems for multi-lingual exploration. It is hard to switch
> 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.
> * Show only a short list of the relevant languages for> 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 <pginer@wikimedia.org>
> 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:
> the user based on geo-IP, previous choices and browser> * Include a "more" option to access the rest of the
> settings of the current user. The language the users
> are looking for will be there most of the times.
> languages for which the content exists with an> * Provide a list of the rest of the languages that users
> indicator of the number of languages.
> 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
> Design@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/design
_______________________________________________
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design