Making inter-language links shorter

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Making inter-language links shorter

Pau Giner
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 <http://pauginer.github.io/prototype-uls/#lisa> 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<https://www.usertesting.com/highlight_reels/qPYxPW1aRi1UazTMFreR>),
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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making inter-language links shorter

Petr Onderka
There is a user script [1] that does a primitive version of this.
I have found it to be quite useful, so I think it's a good idea to do this
properly.

Petr Onderka
[[en:User:Svick]]

[1]: http://en.wikipedia.org/wiki/User:Lampak/MyLanguages


On Thu, Apr 18, 2013 at 6:50 PM, Pau Giner <[hidden email]> 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 <http://pauginer.github.io/prototype-uls/#lisa>
> 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<https://www.usertesting.com/highlight_reels/qPYxPW1aRi1UazTMFreR
> >),
> 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
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making inter-language links shorter

David Gerard-2
In reply to this post by Pau Giner
On 18 April 2013 17:50, Pau Giner <[hidden email]> wrote:

> Please let me know if you see any possible concern with this approach.


My first thought is of how upset people were when the first version of
Vector hid the language links by default. I would suggest being sure
there will be little or no similar objection.


- d.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making inter-language links shorter

David Gerard-2
On 18 April 2013 20:43, David Gerard <[hidden email]> wrote:
> On 18 April 2013 17:50, Pau Giner <[hidden email]> wrote:

>> Please let me know if you see any possible concern with this approach.

> My first thought is of how upset people were when the first version of
> Vector hid the language links by default. I would suggest being sure
> there will be little or no similar objection.


(hit send too soon, sorry)

A simple solution that would avoid a similar reaction is: do not do
this by default - make it only for logged-in users who want it that
way.

Possibly for default users, you could put the heuristically-calculated
likely preferred languages at the top. But keeping the rest of the
list below, right there on display, will (I predict) be favoured, as
advertising the many languages of Wikipedia is a strongly-held value
of many Wikimedians.


- d.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making inter-language links shorter

Brion Vibber
I was traditionally in favor of keeping the full language list visible,
but.... it's just too damn big in many cases and is hard to search through
on any device. On touch devices it's difficult to pick a correct item from
the list as all the links are adjacent (though if you zoom it's ok).

Definitely we need something improved, and if we're going to improve it we
need to do it for the default or we're failing to serve 99% of our
readers...

I'm not sure about the current demo; one thing that bugs me is that there's
a very small tap/click target for getting the full language list call-out.
Clicking on "Language" just hides/shows the short list, it doesn't do
anything. Clicking the "settings" gear icon next to "Languages" brings up a
call-out with language-related settings.... none of which help you get to
another language version of the wiki.


On the mobile site we've collapsed the whole thing to an "Other languages"
section or button (depending on if you're in beta mode) at the bottom of
the article, and this seems to have gotten good usability responses from
mobile users.



On Thu, Apr 18, 2013 at 12:47 PM, David Gerard <[hidden email]> wrote:

> On 18 April 2013 20:43, David Gerard <[hidden email]> wrote:
> > On 18 April 2013 17:50, Pau Giner <[hidden email]> wrote:
>
> >> Please let me know if you see any possible concern with this approach.
>
> > My first thought is of how upset people were when the first version of
> > Vector hid the language links by default. I would suggest being sure
> > there will be little or no similar objection.
>
>
> (hit send too soon, sorry)
>
> A simple solution that would avoid a similar reaction is: do not do
> this by default - make it only for logged-in users who want it that
> way.
>
> Possibly for default users, you could put the heuristically-calculated
> likely preferred languages at the top. But keeping the rest of the
> list below, right there on display, will (I predict) be favoured, as
> advertising the many languages of Wikipedia is a strongly-held value
> of many Wikimedians.
>
>
> - d.
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Making inter-language links shorter

mathieu lovato stumpf guntz
In reply to this post by Pau Giner
Le jeudi 18 avril 2013 à 18:50 +0200, Pau Giner a écrit :
> 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
> […]
> 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.

Very nice job, congratulation. For the feedback:
- you may use a plain text label like "additional languages" instead of
a simple "…"
- when you start typing to filter then type backspace, you won't have a
less filtered list again, you have to hit the cross to clear the whole
entry.
- a totaly personal bias : I prefer broon icons like in Gnome instead of
cross, but cross I widely used so I guess it's not a usability issue

>
>
> Please let me know if you see any possible concern with this approach.
>
>
>
> Thanks
>
>
>
>
> --
> Pau Giner
> Interaction Designer
> Wikimedia Foundation
> _______________________________________________
> Design mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/design


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making inter-language links shorter

mathieu lovato stumpf guntz
In reply to this post by Brion Vibber
Le jeudi 18 avril 2013 à 12:57 -0700, Brion Vibber a écrit :
> On the mobile site we've collapsed the whole thing to an "Other languages"
> section or button (depending on if you're in beta mode) at the bottom of
> the article, and this seems to have gotten good usability responses from
> mobile users.

Oh by the way, is there an access to discussion pages on the mobile
version now? Last time I checked it wasn't accessible directly, but at
the begining it wasn't possible to access other languages if I'm not
mistaken, so I thought that may also come with an update.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making inter-language links shorter

Yuri Astrakhan-2
In reply to this post by Brion Vibber
There are a few things (IMO) that should be done to langlist ordering:

* Group by alphabet
People who understand latin alphabet should get a list of all latin-using
languages listed/sorted together. Cyrillic is a separate group, and so are
various asian and middle-eastern languages. I have seen other sites do this
(e.g. Google, but I can't quickly locate an example right now). Having all
languages bunched up together make going through them extremely painful -
one has to skip all the scripts not understood.

* Each wiki site has different ordering requirements - like Hebrew and
Hungarian wikis want English as the first link, or 'nn' uses 'no','sv','da'
before all others. See
pywiki<http://svn.wikimedia.org/svnroot/pywikipedia/trunk/pywikipedia/families/wikipedia_family.py>-
interwiki_putfirst

* Lastly, but IMO - most importantly, we should honor user settings or
browser settings. If my browser sends *Accept Language:
en-US,en;q=0.8,ru;q=0.6*, it would be good to show english & russian at the
top, followed by others.

All this can (and should) be done in javascript, without affecting servers.

And for historical reasons: bug
2867<https://bugzilla.wikimedia.org/show_bug.cgi?id=2867>...
i filed it in 2005, it has over 60 votes (highest count in bugzilla if i'm
not mistaken)...

--Yuri


On Thu, Apr 18, 2013 at 9:57 PM, Brion Vibber <[hidden email]> wrote:

> I was traditionally in favor of keeping the full language list visible,
> but.... it's just too damn big in many cases and is hard to search through
> on any device. On touch devices it's difficult to pick a correct item from
> the list as all the links are adjacent (though if you zoom it's ok).
>
> Definitely we need something improved, and if we're going to improve it we
> need to do it for the default or we're failing to serve 99% of our
> readers...
>
> I'm not sure about the current demo; one thing that bugs me is that there's
> a very small tap/click target for getting the full language list call-out.
> Clicking on "Language" just hides/shows the short list, it doesn't do
> anything. Clicking the "settings" gear icon next to "Languages" brings up a
> call-out with language-related settings.... none of which help you get to
> another language version of the wiki.
>
>
> On the mobile site we've collapsed the whole thing to an "Other languages"
> section or button (depending on if you're in beta mode) at the bottom of
> the article, and this seems to have gotten good usability responses from
> mobile users.
>
>
>
> On Thu, Apr 18, 2013 at 12:47 PM, David Gerard <[hidden email]> wrote:
>
> > On 18 April 2013 20:43, David Gerard <[hidden email]> wrote:
> > > On 18 April 2013 17:50, Pau Giner <[hidden email]> wrote:
> >
> > >> Please let me know if you see any possible concern with this approach.
> >
> > > My first thought is of how upset people were when the first version of
> > > Vector hid the language links by default. I would suggest being sure
> > > there will be little or no similar objection.
> >
> >
> > (hit send too soon, sorry)
> >
> > A simple solution that would avoid a similar reaction is: do not do
> > this by default - make it only for logged-in users who want it that
> > way.
> >
> > Possibly for default users, you could put the heuristically-calculated
> > likely preferred languages at the top. But keeping the rest of the
> > list below, right there on display, will (I predict) be favoured, as
> > advertising the many languages of Wikipedia is a strongly-held value
> > of many Wikimedians.
> >
> >
> > - d.
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making inter-language links shorter

Lars Aronsson
In reply to this post by Pau Giner
On 04/18/2013 06:50 PM, Pau Giner 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.

For how many users is this a problem? How do you estimate
this? I think it's good that the user is a little overwhelmed
with how many languages are available. The use of Geo-IP
will be interpreted as a political tool that tries to enforce
certain languages in certain geographic areas, which would
be contrary to the mission of the Wikimedia Foundation,
that says all the world's knowledge in your own language.

If a user finds it offensive that an article is available in some
languages that she somehow dislikes, let her login and
select which ones should be hidden. The burden should be
on that user. Wikipedia should provide knowledge, not
hide it.


--
   Lars Aronsson ([hidden email])
   Aronsson Datateknik - http://aronsson.se



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making inter-language links shorter

mathieu lovato stumpf guntz
Le 2013-04-19 12:05, Lars Aronsson a écrit :

> On 04/18/2013 06:50 PM, Pau Giner 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.
>
> For how many users is this a problem? How do you estimate
> this? I think it's good that the user is a little overwhelmed
> with how many languages are available.
> The use of Geo-IP
> will be interpreted as a political tool that tries to enforce
> certain languages in certain geographic areas, which would
> be contrary to the mission of the Wikimedia Foundation,
> that says all the world's knowledge in your own language.

What a delight to see someone which is more paranoic than myself on
this topic. ;)


> If a user finds it offensive that an article is available in some
> languages that she somehow dislikes, let her login and
> select which ones should be hidden. The burden should be
> on that user. Wikipedia should provide knowledge, not
> hide it.

On the other hand cluter can be an effective way to hide or obstruct
the access to information.

--
Association Culture-Libre
http://www.culture-libre.org/

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making inter-language links shorter

Pau Giner
In reply to this post by Pau Giner
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<https://addons.opera.com/es/extensions/details/wikipedia-language-bubble/?display=en>
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 <[hidden email]> 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 <http://pauginer.github.io/prototype-uls/#lisa> 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<https://www.usertesting.com/highlight_reels/qPYxPW1aRi1UazTMFreR>),
> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Making inter-language links shorter

mathieu lovato stumpf guntz
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 <[hidden email]>
> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/design


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Making inter-language links shorter

Pau Giner
>
> 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 <
[hidden email]> 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 <[hidden email]>
> > 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
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/design
>
>
> _______________________________________________
> Design mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/design
>



--
Pau Giner
Interaction Designer
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Making inter-language links shorter

Brion Vibber
Please note that "screen readers" and "readers without JavaScript" aren't
in any way the same thing -- modern screen readers hook into "real
browsers" like IE, Safari, Chrome, and Firefox and JavaScript runs just
great in them.

Serious accessibility concerns should really be referred to someone who's
an expert... do we have anybody on staff or volunteer who has real, direct,
current experience with vision-impaired users and their needs?

-- brion


On Wed, Apr 24, 2013 at 11:51 AM, Pau Giner <[hidden email]> wrote:

> >
> > 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 <
> [hidden email]> 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.
> >
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Making inter-language links shorter

Sumana Harihareswara-2
https://www.mediawiki.org/wiki/Accessibility has a list of "People and
organizations working on MediaWiki accessibility" including Sami
Mubarak, who works on the accessibility of MediaWiki for the blind (in
Arabic).  I've cc'd Sami.

Hope this helps!

--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

On 04/24/2013 03:17 PM, Brion Vibber wrote:

> Please note that "screen readers" and "readers without JavaScript" aren't
> in any way the same thing -- modern screen readers hook into "real
> browsers" like IE, Safari, Chrome, and Firefox and JavaScript runs just
> great in them.
>
> Serious accessibility concerns should really be referred to someone who's
> an expert... do we have anybody on staff or volunteer who has real, direct,
> current experience with vision-impaired users and their needs?
>
> -- brion
>
>
> On Wed, Apr 24, 2013 at 11:51 AM, Pau Giner <[hidden email]> wrote:
>
>>>
>>> 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 <
>> [hidden email]> 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.
>>>
>>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Making inter-language links shorter

Federico Leva (Nemo)
In reply to this post by Pau Giner
I think this is one of the most amazing achievements the ULS will allow
us, thanks Pau.

Pau Giner, 18/04/2013 18:50:

> 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).

The interface is IMHO fine: if done well, this supersedes any problem of
link sorting and (hopefully) also any temptation to just collapse the
list of languages (a bad thing in every and all cases).

The problem is the selection of languages. Will the languages shown by
default those that ULS shows under "most common languages"?
        There's a fundamental difference here compared to interface language
choice: that the user doesn't know in advance what language to look for,
because the article may exist or not. Search, in this case, is often
useless, unless you're in the "wrong language" and you want to go to the
"right language", which is an important usecase but not the only one.
        If I'm presented with the list of all the "common languages", I will
occasionally be bothered by a long list of annoyingly useless dialects
of Italy, but it's so rare and person-dependent problem that it's indeed
not worth looking at. The problem is rather with the languages that I
will most likely not "know" but are always of some value, like Latin,
Spanish, Portuguese, French. I don't want to look for those languages
one by one with the search, nor to skim for them in multiple lists;
grouping by script is completely useless for Latin script, so many
languages use it (even ancient greek is more commonly studied in Italy
than most latin script languages).
        In short, I think the list of languages shown by default should
probably be more "generous" than with the ULS standard, and that all the
(main) languages of the same *family* should be shown in it.

Nemo

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Design] Making inter-language links shorter

Federico Leva (Nemo)
In reply to this post by Pau Giner
 From the various roadmaps and plans I don't understand: is this project
still on the radar, is it going to be worked on in 2013-14?

Nemo

Pau Giner, 18/04/2013 18:50:

> 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
> <http://pauginer.github.io/prototype-uls/#lisa> 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
> <https://www.usertesting.com/highlight_reels/qPYxPW1aRi1UazTMFreR>), 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l