Universal Language Selector/Testing

Summary of the insights obtained from the usability testing sessions performed for the Universal Language Selector.

Language list: Which mechanisms are most useful for looking for a language?

 * Short lists work. When the language that the user is looking for is anticipated in a short list, it is noticed and used by the user.
 * List layout and grouping work. Grouping languages by region and script seem to be beneficial when scanning the list. Users were able to discard big groups of languages based on their grouping.
 * Search is the primary option. Users preferred to search most of the time as the first option for looking up a language.
 * Users are more prone to use search when the search box takes the input focus once the selector is opened.
 * Users try 2 to 3 times to adjust the search query before give up. The first attempt is the language name (using local name or English name). The second may be: try it again (in case of a typo), ISO code, name in a different language, or even country name.
 * Flexibility in search was appreciated. Due to limitations in the prototypes most failed searches were due to a deviation for the exact name (e.g., due to the use of capital letters, the inability to reproduce a specific special character or a typo) that could be avoided with flexible search. When alternative names were added to Māori (such as "maori", "Maori") the number of tries the user makes is dramatically reduced.
 * The "no results found page" helped users to continue the search by region when search failed.
 * Empty sections obscured results. Due to a limitation in the prototype, labels for sections containing no results were still visible, making it difficult to the user to locate the few sections that contained results.
 * The map is used as a backup mechanism.
 * The three region filter was enough to help the users reduce the search. Some users expected to be able to access sub-regions by clicking on them in the map (access Oceania instead of Asia when they click on that sub-region).
 * Some users make use of it as first option for filtering but most make use of it after a failed search.
 * Scrolling the list is also an option. Using the scroll wheel to move through a continuous list of languages was the first option for some users. The division of the list by regions and the synchronization with the map helped them to be in context.
 * The more attempts, the less attention. It was observed that after several failed attempts to look for a language, the probability of the user failing to see that the language is in the list increases.
 * Problems closing the selector. Users found it difficult in some versions of the prototypes to close the language list when it was open by accident.

Language settings

 * Users expected to find input method configuration closer to the editing context. Some users started to search for possible options closer to the text area and did not locate the input settings under general language settings.
 * Some users tried to use the "Special Characters" link at the editor to write in a different language.
 * Initial results with ULS editing support responded to these needs.


 * Problems distinguishing display and input settings. It was not clear for some users whether they were changing input or display settings.
 * Prototypes were updated to better emphasize the current section and the problem no longer appeared in tests.


 * The default input method is not understood. When users select a different input language, they do not normally pay attention to the available input methods. This is expected to be alleviated by:
 * Providing feedback on language change.
 * Editing support.
 * Avoiding symmetry. Since input method section will be shown for languages where different input methods are available. This part of the UI will only appear when it is relevant.
 * Using a different method than "default" as the initial default.


 * Showing multiple languages as the current ones creates confusion. For some tests, keyboard and a label with the ISO code was used to indicate the current input language.
 * The icon was helpful most of the cases but the label was not associated with input but content language.

Location for the Selector

 * Using two different locations for language-related settings creates confusion. Previous test shown users get confused when both interlanguage links and the ULS are placed at different locations.
 * Integration with interlanguage links (Option B) works. It works great especially for content and UI changes.
 * When editing users expect to find a more clear clue (keyboard icon, or some aid closer to the text area). Edit support seems to solve that.
 * Top-right location (Option A) works when it replaces interlanguage links. Users notice the big change but they adapt well.
 * Users noticed that links were not in their usual position but they considered that the top-right placement made sense since it was common for other websites.
 * Users perceived the top-right zone as a settings area.


 * Making the interlanguage links more compact (using the short list of languages) works well.
 * Users were able to understand that the list continues and access the rest of languages from the list.


 * Both icons were suited to their purpose.
 * The language change icon was considered to catch the user attention and convey the meaning of "language change".
 * The Cog icon, was considered not to attract the attention as the previous one but to better convey the meaning of "settings".


 * Editing support was appreciated and understood.
 * For tests where editing support was not provided, users expected the input language configuration closer to the editing.
 * Confusion how to disable the current input method. Options considered: Better convey that the check mark can be unchecked or include an explicit option.