Universal Language Selector/Interaction Design Framework

This is the design concept page for Extension:UniversalLanguageSelector.

User Scenarios

Definition of the behavioral variables, user profiles and scenarios

To better illustrate the intended purpose of the Universal Language Selector, several scenarios have been defined. The complete definition is available in a separate document. Here a summary has been included in this section.

To create representative scenarios, the behavioral variables that affect interaction have been analyzed and structured on four user profiles.

Behavioral variables

A set of factors that affect the way in which a user select a language have been defined. These variables have been identified by analyzing different sources of information (bug reports, talk pages for existing documentation) and gathering feedback from members of the Wikipedia community and members of the Localisation team.

The variables identified are the following:

• Number of languages spoken by the user (one, two, several)
• Skill level for each language (no, bad, basic, good/native)
• Kind of language spoken by the user:
  • Writing direction for the language (LTR, RTL)
  • Number of speakers (many, few, none/historical)
  • Geographic distribution (shared with other languages, spoken in multiple geographic areas, spoken in a single area)
• User main activity (consuming content, searching, contributing content)
• User location (native country, non-native country where the user can communicate, foreign country)
• Familiarity with language features (not familiar, basic use, advanced, expert)
• Device used for access (tablet, desktop/laptop)
• User account (anonymous, registered)

This is not intended to be a complete scientific taxonomy. The purpose is to facilitate the evaluation of design solutions.

User Profiles and scenarios

Each combination of values of the former behavioral variables defines a specific kind of user for which the ideal interaction may be different. A small subset of user archetypes has been defined to cover the behavioral variables to the widest possible degree. A summary of the profiles defined and the scenarios is profiles below, the attached PDF includes a more detailed description.

Nambi

Nambi is a nurse from Paraguay that speaks Guaraní and Spanish. She contributes content in Guaraní and consumes content in both languages. She is a registered user and makes basic use of the existing language tools.

Her goal is to contribute to the Guaraní community:

• Contribute local content. Nambi realizes that there is not a Guaraní version of an article She is reading in the Spanish Wikipedia. She creates a new article based on a translation of the Spanish one. She keeps jumping from one version to the other during the translation process.
  • Features: Support recurrent language change among a small set, access to local-spoken languages, and indication of lack of language support.
• Setting the UI. Nambi prefers the user interface menus to be in Guaraní. She becomes aware that registered users can customize their UI language and changes this.
  • Features: Discoverability of UI language settings, and distinction between UI and Content language settings.

Rakha

Rakha is a musician from India, currently in Belgium. He speaks Tamil (native) and English (very basic). He searches and consumes content from the public PC at the hotel. He is not a registered user and he is not familiar with language tools.

His goal is to feel like at home (despite being abroad):

• Search in his language. Rakha accesses the Wikipedia in Tamil but the public PC at the hotel has a French keyboard. Rakha finds guidance on how to introduce a few Tamil characters for the search. When he finds little information on the subject, he switches to the English version for a moment.
  • Features: Discoverability of input method configuration, aids for accessing input method configuration during text input, terminology used to communicate input method configuration, and discoverability of relevant content in other languages.
• Cross-language information. Rakha has accessed the Tamil version of Wikipedia, but he is looking for information on a Belgium dish he only saw written in French. He searches for the dish name in French, but he is interested to access the information in Tamil.
  • Features: Disable/re-enable input methods, and cross-language access of search results.

Lev

Lev is a professor from Israel. He speaks Russian, Hebrew, and studies Old Aramaic. He is a registered user with deep knowledge of language tools and contributes content in these three languages from a PC.

His goal is to share knowledge about his topics of interest:

• Extensive contributions. Lev makes large contributions in Cyrillic to the Russian Wikipedia. He uses different keyboards at work (lacking Cyrillic mapping) and at home (a Latin-Hebrew-Russian keyboard).
  • Features: Input method configuration UI support for long texts, integration of system configured input methods.
• Mixed content. Lev studies Old Aramaic and includes content in Aramaic for Hebrew and Russian articles.
  • Features: Indication of current language for each piece of content.
• Translation across languages. Lev helps to translate content between Russian and Hebrew and registers as a translator for both languages.
  • Features: Multiple language selection.

George

George is an architect from Georgia that speaks only Georgian and consumes content from his tablet. He is not a registered user and he is not aware of language tools such as the inter-wiki links.

His goal is to learn about new topics in his own language:

• Properly displayed content. George access the Georgian version of an article and everything is properly displayed.
  • Features: non-intrusive UI, proper font display for non-latin scripts.
• Recover from a foreign language. George access the English Wikipedia through a friend's link, and figures out how to access the Georgian version.
  • Features: intuitive location for language selection.

Prioritization

All users are important, but in order to achieve a focused design user profiles have been prioritized. Nambi and Rakha have been considered as primary users, while Lev and Gorge have been considered as secondary users. The main selected users represent users that make use of language selection without a deep previous experience. The rationale is that optimizing interaction for the primary users will suffice either advanced users such as Lev (since they are technically skilled) and non-technical users such as George (which do not have a high demand for language tools).

Design goals

The following goals have been defined:

• Discoverability. The selector and their features are easy to find.
• Fluency. The solution should interfer minimally with the main flow of tasks for the user. Changing settings related to language should be fast and not distracting.
• Learnability. The way in which the selector is operated and the effects of each action should be easy to anticipate.

An initial plan for validation of the design solutions has been defined, and it is summarized below.

How to measure that the goals are achieved

Test scenarios have been defined to evaluate prototypes.

Prototypes will be build to test the different design solutions. For the 2-3 most promising design concepts, two rounds of testing will be carried out with 3-5 users per prototype.

Each validation stage will consist in the following steps:

1. Classify the participants. A short survey based on the behavioral variables identified will be completed by each participant. This will determine how the user fits in the types of users defined.
2. Perform the usability tests. Users will use prototypes to carry out some test scenarios.
3. Analyze the results. Design solutions will be modified/discarded according to the feedback obtained.

What to observe

Criteria to evaluate different design solutions and determine whether they are improving the current solution have been defined. This includes gathering quantitative data (we can measure them) and qualitative data (we can infer them by watching the use of the product and confirm them by asking). The observations of interest are the following for each design goal:

• Discoverability. Language selector is easy to find.
  • Measure the success ratio: how many users found the way to change the language.
  • Measure the time to find the selector: time spent since the user starts looking for the language selector until they click on it
  • Ask: Do you think this information is provided in other languages?
• Fluency. Language selector is quick to operate and non-distracting.
  • Measure the time to select languages.
  • Ask: Do you think changing between languages is fast?
  • Ask: Does the language selector distracted you from your main goal of looking for information?
• Learnability. Language selector is easy to learn.
  • Measure the number of aids used when changing language.
  • Ask: Which elements do you see in the selector and which do you think its purpose is?
  • Ask: Which effect do you think it will have to select a language from this list?

Limitations for the testing

Several issues specific to the project limit the testing process:

• Prototype-user language alignment. The prototype language must be aligned with the language of the user testing it. This require to either limit the scope of the participants to recruit, or elaborate the prototypes in such a way that texts can be easily replaced by appropriate translations (increasing their complexity of the prototype elaboration).
• Configuration for text input. Advanced features related to input such as as transliteration are difficult to integrate in prototypes. Tests will be defined in such a way that these features could be simulated as much as possible.

Interaction Design Framework

In order to explore different design solutions in a systematic way, we have defined: the pieces that compose the Universal language Selector, the steps performed by the user and a collection of ideas to support the design goals.

Concept Model: the anatomy of the selector

Some of the concepts that are involved in the selector, have been depicted in a concept model.

The design solutions should consider the following concepts:

• The trigger. The selector is activated by an element that provides access to the language selection. In the simplest case it may be a a "select language" label and a button that opens a dialog to allow the language selection. The mechanism for activating the selector is something that requires much thought and care. Users who do not speak English, for example, may not understand that the glyphs "Select Language" mean exactly that. It must be assumed that the user is not familiar with the language used by the site chrome.

• Language list. The set of languages that are provided as an option. To make it easy to manipulate, the list can include aids for navigation and aids for presenting the different languages. Some of these aidss can be based on contextual information such as the languages spoken in the location the user is accessing from.

• Input and display settings. Allow the adjustment of input methods and font settings and provide guidance on how to adjust these settings.

• Current language indicator. Indicates the current selected language (or languages if the context requires multiple selection).

• Context where it is used. The language selection can be performed with different purposes: change UI/content language, create a list of languages, or set global user preferences.

These concepts have been illustrated in a Concept Model. This concept model will be useful for breaking down the design solutions in pieces for which we can generate ideas and we can combine solutions. The interaction framework section uses these concepts to define directions to generate solutions.

Workflows: steps for language selection

Depending on the activity the users are involved in, the language selection is performed in a different manner. The proposed solutions should consider the steps the user makes in each case to make their workflow as fluent as possible.

Workflows have been analyzed for the following situations:

Workflow describing actions when language is changed

• Single-language selection. The language selection flow defines the steps the user performs when selecting a language. Critical points are the location of the trigger for the activation and the mechanisms the language list provides for reducing the complexity of finding the desired option among hundreds of alternatives.

Different alternatives to perform multiple selection.

• Multiple language selection. For multiple language selection, two alternatives can be used in terms of user workflow: action-based or status-based. The action-based approach consists in repeating the process of selecting one language for each language the user wants to select. The status-based approach allows the user to indicate whether each language is selected or not and modify his selection in a single step.

Workflow for input method selection.

• Input method selection. For input method selection we have identified two key points: when the user becomes aware that he cannot introduce text in their desired script, and when the user requires help for using the tools.

Mental model: aligning features with needs

A mental model has been defined to align the different ideas for the design (bottom of the diagram)with the user goals and needs (top of the diagram).

From the defined scenarios several user needs were identified. We have defined a mental model diagram to align these needs with the design goals and the possible features of the language selector. User needs are represented at the top of the diagram. For each need a set of potential features are presented at the bottom of the diagram.

Fluency of use

• Display content properly:
  • Automate font download. Make the font download enabled by default.
  • Font customization settings. Provide capabilities to chose among different fonts.
  • Use sensible defaults to hide advanced settings. Some adjustments can be moved to a separate section to simplify the main settings interface.
  • Warn when fonts are disabled to allow users to recover. Show a warning to the user when he relies on the system fonts and a non-latin script is displayed.
• Use from a tablet device:
  • Use big tap targets. Clickable elements should be big enough for both mouse and fingers.
  • Allow gestures for scrolling. Support the scrolling gesture on a surface to scroll its content apart from scrollbars.
  • Adapt some widgets to fit screen real state. For elements that require too much space, responsive design techniques can be applied to adapt to the tablet version.

• Find the language quickly in a list:
  • Anticipate likely elements in the trigger. Provide a list of candidate languages right into the trigger as a shortcut to language selection.
  • Emphasize local languages. Languages spoken in the country the user is accessing from are presented in a way that is easier to find.
  • Emphasize browser-configured languages. Languages defied in the browser configuration are presented in a way that is easier to find.
  • Group languages by script type. Languages using the same script are visually placed together.
  • Allow text search to filter the list. User input can be used to locate the language.
  • Hide initially the less-frequent languages. Prioritize the common used languages by hiding the less common ones in a deeper level of navigation.
  • Automate default language selection. Make language selection automatic based on contextual information.
  • Indicate languages are not available. Suggest that a language which the user is likely to select is not available.
  • Emphasize previously selected languages. Make previous selected languages easier to find.

Findability

• Jump among a set of languages:
  • Shortcut to 'undo' previous changes. Once a new language is selected, provide a shortcut to select the previous one.
  • User specified favourites. Let the user choose a set of languages which will be later made easier to find.
  • (Re)enable and disable input aids while editing. Provide shortcuts in the editing context.
• Locate the selector easily:
  • Easy to find placement. Place the selector in a location that is easy to find by the user.
  • Use an icon to identify language selection. Announce the selector graphically.
  • Use languages in their own script. Use language labels written in their own languages to identify each language.
• Find language settings.
  • Easy to find placement. Place the settings in a location that is easy to find by the user.
  • Use cross-links from language related tools. For each tool that may requite a language settings adjustment, include a link to language settings.
• Find input method configuration when needed.
  • Show shortcut to configuration when editing text.
  • Show shortcut to configuration on first removal.
  • Prioritize methods available for the current language. Filter initially the available input methods to show the ones that are available for the current language.

Learnability

• Distinguish UI from content.
  • Present as separate concepts. Make clear in the selection which concept is being adjusted.
  • Link to user settings UI. Separate UI and content configurations but provide links between them.
  • Select content and indicate optionally whether to propagate the decision to the UI. Make content selection the default but allow to opt-out the UI change.
  • Present UI language as "Language for menus". Use a non-technical term for referring to the UI.
• Explain input method config.
  • Provide help information. Provide guidance on the different options included in the configuration.
  • Present input method as "input language". Provide the selection between keyboard layouts when more than one is available.
• Make clear the consequences of the selection.
  • Add checkboxes for multiple selection. Allow state-based selection for multiple selection.
  • Use a selected list for languages added. Include a list of selected languages where languages can be added/removed.

Principles and patterns

Design principles

• Make the user interface transparent. Language selection tools do not provide direct support of a specific user goal (e.g., find information) but provide mechanisms that make these goals easier to achieve. The experience should be transparent for two different usage patterns: sporadic use and repetitive use.
• Provide tools where they are needed. Language selection is performed as a complement for certain tasks, the more easy it is form the user to find the selector while performing these tasks, the better.
• Optimize for the probable, provide for the possible. The Universal Language Selector may be used by many different users in different contexts. Solutions proposed should make it easier to use for our target users without representing barriers that make the tool unusable for the rest.

Design patterns

Design patterns that can be applied to the Universal Language selector have compiled in this section to discuss their benefits and limitations. These are general interaction solutions that can be used i one or more of the ideas described in the mental model.

Autocompletion

As the user types what he is looking for, the system provides possible answers for the user to choose from. This pattern can be applied to free text searches or searches in a large but finite domain such as your list of contacts when sending an email. Suggestions can be provided even before the user types a single character. For the selector, language list can be hiden by using autocompletion. A solution for the language selector based on autocompletion was proposed by Guillaume Paumier.

Benefits:

• Saves time. The user is not required to (a) explore all the possible answers, or (b) type the full answer.
• Allows flexible input. Once the user starts typing, the suggestions can be provided as a result of different heuristics. Given two characters introduced by the user, suggestions can contain languages that contain these two characters in their name (in their own language or in a different one), languages that use these characters as part of their ISO code, and previous languages selected by the user.

Limitations:

• Requires the use of keyboard. To take advantage of the feature, typing is required. This can be a problem for (a) users which are mainly consuming content, and (b) tablet users where the keyboard consumes a great percentage of the screen and represents a greater change of context.
• Difficult to explore. Autocompletion do not expose the full list of choices to the user. Thus, when the user does not find the desired suggestion he is not sure whether he is not typing it in the appropriate way or the solution does not exist at all.

Inline edit

An element which is used for displaying state, when operated it is transformed into an editable element. More information about the pattern. For the case of the selector, indicators of current language or input method can turn into a selection mechanisms as an alternative way of changing them.

Benefits:

• Reduces complexity. Edition elements are removed from first-sight, which is good if the primary purpose of the element is to display.

Drawbacks:

• Difficult to discover.Since edition elements are hidden, they require the user to discover them. It is important to provide an adequate invitation to act.

Responsive disclosure

Parts of the interface that depend on a specific decision can be hidden until the decision is made by the user. This can be applied for the case of language-relate settings since different dependencies exist.

Jennifer Tidwell provides more detail about this pattern.

Benefits:

• Complexity is reduced. The user is offered choices only when they make sense.

Limitations:

• Information is hidden. If the user is looking for a specific sub-option, he may overlook it.

Iconography to represent languages

There is (at the time of this writing) no universal icon for "select language". Some sites utilize "flag" iconography but this not acceptable because:

• Flags are not culturally neutral. There are more English speakers in India than there are in the United States, for instance.
• Language is not "owned" by any one political organization. Is "English" best served by the flag of the United Kingdom, Canada, United States of America, Australia, or any one of other nations that recognize English as an official language?
• Users typically have very low "flag literacy". Not all flags are known to all peoples.
• Flags can be political hot-buttons. Not all nations are recognized by all nations.
• Flags have potential "expiration dates". Nations do not exist in perpetuity; they rise and fall. They may also change their flag symbology and colors.
• Flag systems require maintenance for accuracy.

At this point in time, the best developed icon for this type of function is a stylized, wireframe globe. The globe should not display any land mass areas for two main reasons: cultural neutrality (which country is on the front of the globe) and for resolution-at-scale issues (reading the icon at 16x16 pixels).

Design directions

The solutions proposed will explore different design directions. For each aspects different options have been provided, but these options should not understood as binary, but a whole range of designs can target intermediate positions. In general terms the main design directions to explore are:

• Minimal contextual selector. Define a selector that is almost invisible, but offers help where it is needed. By taking advantage of contextual information, it provides the most likely options.
• Helpful exploration. Define a selector that exposes the available options but provides as much help as it is possible to re-arrange information easily.

More detailed aspects that can be adjusted are listed below.

General

• Look like a single component.
  • Totally unified. The selector is presented as a single component where language-related actions and configurations are accessed.
  • Related components linked together. The selector can be presented as different components for which it is easy to jump among them.

• Adapt to user context.
  • Adaptable: Information will be organized and located differently depending on the user current and previous actions, location, browser configuration, etc.
  • Consistent. The UI will be the same regardless of the user context.

The trigger

• Trigger location.
  • Global. A single entry point is provided for activating the selector in a location that is consistent and easy to locate.
  • Contextual. The trigger is placed closer to where it is needed.

• Trigger connection with the language list.
  • Separate. The language list is shown in a different view.
  • Connected. The language list is shown as an adjacent view when activated. From this moment, the trigger is not operated for language selection.
  • Integrated. The trigger is extended to act as the language list.

• The trigger includes complementary information.
  • No.
  • Number fo available languages.
  • Current language(s) selected.
  • Subset of the language list.
  • Icon.

Current language indicator

• Acts as a trigger.
  • No.
  • Yes.

• Is feedback provided when the language is changed.
  • No.
  • Announce the change.
  • Provide additional information and actions (to revert, or jump to other languages).

Language list

• Provides navigation aids:
  • Filter by geographic region.
  • Provide a meaningful ordering.
  • Provide grouping.
  • Provide pagination.
  • Provide (vertical/horizontal) scrolling.

• Which languages are emphasized.
  • Browser configuration ones.
  • Locally relevant.
  • Previous choices.
  • Most spoken.

• How are languages emphasized.
  • Size.
  • Order.
  • Background color.
  • Prominent position.

Multiple selection

• Flow to support.
  • Select and repeat.
  • Check and uncheck.

• Where to display the current selection.
  • At the trigger.
  • At the language list.

Settings

• User guidance
  • Show all choices.
  • Step by step guidance.

• Input text settings integration:
  • Global position
  • Link to settings
  • Embed relevant settings close to the input element.

How to use the framework

The steps for defining a solution will be:

1. Define which area to explore from the design directions.
2. Select which ideas to incorporate in the solution from the mental model defined.
3. Select the elements to address form the concept model (you can design the whole selector or just the trigger).
4. Use design patterns as a toolbox for specific executions of the ideas (evaluate whether they apply to the specific context first).
5. Make a sketch of the solution.
6. Ask yourself whether the solution follows the design principles.
7. Imagine the different user profiles using the tool in their scenarios. Pay attention to the support the solution provides to each step defined in [#workflows|the workflows].