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 recordinghttps://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
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 Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
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 extensionhttps://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
Only consideration from Wikidata point of view is to either keep the "edit links" link to Wikidata (eventually with a widget) or some better solution.
Also, I think we need some fairly obvious place, probably in addition to that simply shows there is a "connection" or not between a Wikipedia page and Wikidata. If so, it have a link to the associated Wikidata item. Suggestions and ideas welcome.
Cheers, Katie
On Fri, Apr 19, 2013 at 8:19 PM, Pau Giner pginer@wikimedia.org wrote:
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 extensionhttps://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 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:
- 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 prototypehttp://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 recordinghttps://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
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Only consideration from Wikidata point of view is to either keep the "edit links" link to Wikidata (eventually with a widget) or some better solution.
Although the "edit links" does not appear in the prototype, the design is not intended to change the basics of interlanguage links. So it is supposed to play well with other extensions.
Also, I think we need some fairly obvious place, probably in addition to
that simply shows there is a "connection" or not between a Wikipedia page and Wikidata.
I think it would be great to have an entry point to access a Wikidata "card" (e.g., in the style of Google Now cards) that summarises the info on the current item and allows you to navigate to related info or link to it. Wikidata items and their connections have a great potential, but also present interesting challenges form interaction design and information visualisation sides.
I'll be happy to think more on that, and if you are attending the Amsterdam Hackathon, we can keep the discussion on this topic.
On Fri, Apr 19, 2013 at 9:05 PM, Katie Filbert katie.filbert@wikimedia.dewrote:
Only consideration from Wikidata point of view is to either keep the "edit links" link to Wikidata (eventually with a widget) or some better solution.
Also, I think we need some fairly obvious place, probably in addition to that simply shows there is a "connection" or not between a Wikipedia page and Wikidata. If so, it have a link to the associated Wikidata item. Suggestions and ideas welcome.
Cheers, Katie
On Fri, Apr 19, 2013 at 8:19 PM, Pau Giner pginer@wikimedia.org wrote:
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 extensionhttps://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 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:
- 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 prototypehttp://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 recordinghttps://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
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Katie Filbert Wikidata Developer
Wikimedia Germany e.V. | NEW: Obentrautstr. 72 | 10963 Berlin Phone (030) 219 158 26-0
Wikimedia Germany - Society for the Promotion of free knowledge eV Entered in the register of Amtsgericht Berlin-Charlottenburg under the number 23 855 as recognized as charitable by the Inland Revenue for corporations I Berlin, tax number 27/681/51985.
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
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@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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
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
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
Op 4 sep. 2013 om 08:19 heeft "Federico Leva (Nemo)" nemowiki@gmail.com het volgende geschreven:
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?
It's not planned for Language Engineering in 2013-2014.
Siebrand
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.
Siebrand Mazeland (WMF), 04/09/2013 08:50:
Op 4 sep. 2013 om 08:19 heeft "Federico Leva (Nemo)" het volgende geschreven:
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?
It's not planned for Language Engineering in 2013-2014.
Too bad. Thanks for the prompt answer.
Nemo
On 09/04/2013 01:26 AM, Federico Leva (Nemo) wrote:
Siebrand Mazeland (WMF), 04/09/2013 08:50:
Op 4 sep. 2013 om 08:19 heeft "Federico Leva (Nemo)" het volgende geschreven:
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?
It's not planned for Language Engineering in 2013-2014.
Too bad. Thanks for the prompt answer.
Maybe a candidate for
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects ?
fwiw: next month the current Google Summer of Code / Outreach Program for Women rounds will be over and we will refresh that page for the new OPW round starting in January.
Quim Gil, 04/09/2013 21:50:
Maybe a candidate for
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects ?
fwiw: next month the current Google Summer of Code / Outreach Program for Women rounds will be over and we will refresh that page for the new OPW round starting in January.
I'm not the PM in the room, but I highly doubt it fits the 3-months-project frame, especially given how impactful and sensitive an area of the skin(s) interwikis are.
Nemo
I highly doubt it fits the 3-months-project frame, especially given how impactful and sensitive an area of the skin(s) interwikis are.
I'm not sure if it fits on a 3-month period, but I think that some aspects may help to it:
- I agree that interlanguage links are a sensitive area. But this concern can be solved by adding the feature by means of BetaFeatureshttps://www.mediawiki.org/wiki/Extension:BetaFeatures, so that our community members can opt-in to test it and see how it works in practice for all kinds of articles. - From the technical side, the most complex pieces are already available (e.g., getting usual languages based on geo-ip and previous selections, language selection UI) which would help to speed the development.
Pau
On Wed, Sep 4, 2013 at 10:19 PM, Federico Leva (Nemo) nemowiki@gmail.comwrote:
Quim Gil, 04/09/2013 21:50:
Maybe a candidate for
https://www.mediawiki.org/**wiki/Mentorship_programs/**Possible_projectshttps://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects?
fwiw: next month the current Google Summer of Code / Outreach Program for Women rounds will be over and we will refresh that page for the new OPW round starting in January.
I'm not the PM in the room, but I highly doubt it fits the 3-months-project frame, especially given how impactful and sensitive an area of the skin(s) interwikis are.
Nemo
______________________________**_________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/designhttps://lists.wikimedia.org/mailman/listinfo/design
This sounds like a perfect thing for Beta Experiments, as Pau mentioned. The page he linked to talks about how developers can package their code to add to BE framework here is a bit more about what BE is and why it exists. http://www.mediawiki.org/wiki/Lab_experiments
Mark Holmquist is the developer on the feature I'm sure he can help with any issues, he's also working on documentation for the feature as well.
* * * * *Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Sep 5, 2013 at 9:19 AM, Pau Giner pginer@wikimedia.org wrote:
I highly doubt it fits the 3-months-project frame, especially given how
impactful and sensitive an area of the skin(s) interwikis are.
I'm not sure if it fits on a 3-month period, but I think that some aspects may help to it:
- I agree that interlanguage links are a sensitive area. But this
concern can be solved by adding the feature by means of BetaFeatureshttps://www.mediawiki.org/wiki/Extension:BetaFeatures, so that our community members can opt-in to test it and see how it works in practice for all kinds of articles.
- From the technical side, the most complex pieces are already
available (e.g., getting usual languages based on geo-ip and previous selections, language selection UI) which would help to speed the development.
Pau
On Wed, Sep 4, 2013 at 10:19 PM, Federico Leva (Nemo) nemowiki@gmail.comwrote:
Quim Gil, 04/09/2013 21:50:
Maybe a candidate for
https://www.mediawiki.org/**wiki/Mentorship_programs/**Possible_projectshttps://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects?
fwiw: next month the current Google Summer of Code / Outreach Program for Women rounds will be over and we will refresh that page for the new OPW round starting in January.
I'm not the PM in the room, but I highly doubt it fits the 3-months-project frame, especially given how impactful and sensitive an area of the skin(s) interwikis are.
Nemo
______________________________**_________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/designhttps://lists.wikimedia.org/mailman/listinfo/design
-- Pau Giner Interaction Designer Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Thu, Sep 05, 2013 at 11:48:53AM -0700, Jared Zimmerman wrote:
This sounds like a perfect thing for Beta Experiments, as Pau mentioned. The page he linked to talks about how developers can package their code to add to BE framework here is a bit more about what BE is and why it exists. http://www.mediawiki.org/wiki/Lab_experiments
Mark Holmquist is the developer on the feature I'm sure he can help with any issues, he's also working on documentation for the feature as well.
Still in medium-heavy development, but documented and nearly ready for pre-deploy review. If you catch any problems, give a shout and I'll fix it as soon as I can!
Ta,