Universal Language Selector/Testing

Testing the prototypes
Summary of the insights obtained from the usability testing sessions performed for the Universal Language Selector:
 * Two pilot tests were performed on the 5th and 16th of May 2012 to adjust the initial prototypes.
 * A first round of tests was performed with 4 users between 25 May and 4 June.
 * A second round of tests were performed with 6 users between 11 and 22 of June.

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.

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.