[Mediawiki-i18n] [Design] Making inter-language links shorter
Pau Giner
pginer at wikimedia.org
Wed Apr 24 18:51:33 UTC 2013
>
> Also, did you think of the accessibility issues in your solution?
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.
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.
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.
On Sat, Apr 20, 2013 at 2:04 AM, Mathieu Stumpf <
psychoslave at culture-libre.org> wrote:
> 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 <pginer at 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:
> > * 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
> > Design at lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/design
>
>
> _______________________________________________
> Design mailing list
> Design at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/design
>
--
Pau Giner
Interaction Designer
Wikimedia Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/mediawiki-i18n/attachments/20130424/1745175c/attachment-0001.html>
More information about the Mediawiki-i18n
mailing list