Chinese (中文) – Flags are not languages

Case study: onefinestay.com and dropdown language selection

Key lessons learned (the TL;DR version):

users are easily able to find translation links in footers
language names work well at communicating links to translations – but only if the user is familiar with that alphabet (for instance, as English-speaking user won’t recognize Chinese lettering if Chinese is the current language)
the use of flags do not aid users more than listing language names and using other iconography for selectors
be careful when using online remote testing. Careless participants can skew your outcomes

onefinestay is a holiday/vacation rental service with a difference: it aims to give you the chance to stay in someone’s place while they’re out of town and “live their life”. They consider themselves an unhotel.

Currently they operate in four cities: New York, Los Angeles, London and Paris. While most of their users are US-based, they receive significant traffic from users who speak French, Spanish and Portuguese.

While their site is currently only available in English they are looking at providing localised versions. This is especially important considering their service in Paris which is only available through an English interface. Working with their Product Manager Matt Isherwood (a former colleague of mine), we started to discuss what the best way to present multiple languages on the site would be. User testing these approaches was the obvious way forward.

The first design aimed to integrate language selection as a sub-option within a user management dropdown represented by a user icon (see below for screenshot). This would also contain other site settings such as currency and other account information.

Using UsabilityHub for super-fast remote testing some interesting outcomes and insights were discovered.

The test? Prior to seeing a screen, users were given the following instructions:

While looking for a place to stay in Paris you find this page. Where would you click to view a version in English?

Test users would then see a full-screen mock up of a onefinestay page translated into French in which hopefully they would be able to find a way to navigate to the English-language version of the site.

Partial screenshot of test screen

Iteration one: user icon

Would users associate changing language with this icon? I was concerned the task of changing language was too far removed from the sort of user settings this icon usually represents. In a more application-focused product it might (think Twitter or Facebook: language settings are found in user menus). But on a website which doesn’t require logging in why should a user need to access anything under a user management menu – unless, of course, they are logged in?

The first ten tests confirmed this concern. Only one user out of 10 interacted with the icon. However, the remaining 90% (nine users) scrolled to the bottom and found the supplementary language links there.

First lesson: users appear to have no problem finding translation links in footers.

Iteration two: nounproject translation icon

Translation icons come in several varieties but the unofficial convention on these icons tie together an eastern character (often Chinese or Japanese) with a Latin equivalent (usually the letter ‘a’). One such variation found on the nounproject icon library site combines with convention with speech bubbles to create a fairly strong icon for translation.

Would this perform better? I expected it too but wondered if the context of the action wasn’t quite right. This icon feels more suited to the action of translation (think Google Translate or a language dictionary) rather than selection of a site-wide language.

Whether it was context or another factor – and this is where quantitative testing can still leave us in the dark – the icon still failed. It performed better than the icon but only 30% of users interacted with this element (four in total).

However, yet again the remaining 70% users (six total) still found the supplementary links at the bottom of the page. Our first lesson had been reinforced but the menu was still struggling.

Iteration three: globe icon

The globe icon can, unfortunately, be extremely vague. On Facebook – which arguably shapes the visual meaning of this icon immensely — it functions as a notifications icon (although as John Yunker points out, it’s probably one of the best choices for a translation/localisation icon).

Would be global/international meaning work well with the context of this task? It worked better, but still not great: 50% (five users) interacted with it to change the language (and yes, yet again the remaining 50% of users found the language links at the bottom of the page).

While 50% is an improvement, it’s still not satisfactory.

Iteration four: language names

By this point I was concerned the premise of the dropdown was also being lost. So I integrated a downward triangle to better communicate the presence of hidden options below the icons.

By adding a text label for the current language in French (and in French – Français) would this be obvious to users?

Click map showing user clicks from user testing.

The results were promising. To be better sure of these results statistically, I bumped the test numbers up to 20. The success percentage still remained excellent at 95% (19 users). And the one user who didn’t interact with the menu? They also found the English link at the bottom.

This appeared to be a winning option.

Second lesson: perhaps unsurprisingly, language links work very well as language links.

While both the onefinestay design team and I were against using flags for language selection, this seemed an interesting opportunity to test whether flags do indeed signpost language selection any better.

After adding a French flag to the drop down, I repeated the test on an another twenty users. The result? Identical. 95% found the menu link and the other single user still found the footer link.

Third lesson: flags don’t appear to add any extra advantages to this approach.

So we appear to have found a winning formula? Not quite.

What if onefinestay adds a Chinese option to their menu and we change the task slightly: you’re in Shanghai trying to find a place to stay. By following the same approach, this is what a user would see:

(This is not dissimilar a problem recently faced by Anna Kay on the Mozilla site. On her blog she describes being unable to find a language chooser due to all the text on the site being in Chinese).

Based on what I’d seen on the Mozilla site — and Anna’s own testing — there was not much point testing this.

So time for two more tests: one using icons and the other using a flag – just to test our two best performing variants. The globe icon so far had performed the best so I used this along with making the language label blue to give it some more visual prominence – the flag variant already had this thanks to the red of the Chinese flag.

The test script obviously needed to change for this, so the following scene was set for test users:

While looking for a place to stay in Shanghai you find this page. Where would you click to view a version in English?

Click map for the globe icon dropdown

Click map for the flag dropdown. The red dot shows a user hitting outside the hit area trying to find a link to English content

The results from these tests were far less black and white. A small percentage of users (5-10%) could not find the links at the bottom or the dropdown at the top in either test variation. The lack of Latin characters seemed to add an extra layer of confusion on the task.

With the success/failure rate between both test variants ebbed and flowed. At 20 tests each, the flag variant performed better by only two successful user tests — but success rates for both were below 60%. Was this statistically proof enough to show the flag variant being more successful? Not really. In fact statistically both designs looked flawed with such a low success rate (caveat: even if the flag was performing better, I’d still be very weary using flags in this situation for numerous reasons).

However raising the test number to 30 gave a more positive outcome for both: yet again both hit a 66.6% success rate. Only one user on the globe variation failed to find the dropdown or footer links, whereas two users failed both on the flag variation — the remainder found the translation links in the footer.

Again, our third lesson was reinforced: flags don’t offer any much more assistance to users.

With users finding language links in the footer, I wondered whether a dropdown was even necessary. So in the final test I tried a variation of the Chinese page with only links to translated content in the footer.

Click map showing users expecting to find language selector in the top right area

Only 50% out of ten users tested found the footer links in this test: and the clicks shown above strongly suggest that users expect to see some sort of language switcher in the header.

There was a fourth lesson I learnt from this form of testing: one or two careless users can radically skew these results. Along with blowing averages out with poor response time (always be wary with averages: any decision based on an average should only be taken after analysing the full data range) an errant click can easily cast doubt on certain designs.

Unlike a face-to-face test, you can’t guide a user either: if they don’t understand the question then your hypothesis can suffer from whatever action they then take. Distinguishing genuine failures from clicks from test users who don’t care and just want to get through the test can be very tricky. But these outliers can skew your results and should be discounted where possible (and replaced with supplemental tests).

So in conclusion, if you’re planning on implementing a dropdown language switcher, consider the following:

always supplement your dropdown with links in the footer
use a globe or similar icon to communicate translations to the user along with language labels
flags don’t appear to aid nor hinder users compared to using icons/common UI patterns, but by using them you’ll probably find yourself stumbling into several problems outlined elsewhere on this blog.

Language menus: Flags symbolize nations, not languages

From Damian Vila on Dribbble:

Dribbble has several shots of language selectors using flags — however this one raises awareness of the simple fact that flags symbolize nations and not languages.

Smartisan OS and a better way to deal with language selection on devices

Smartisan is a new Android-based mobile operating system designed in China. The launch was in Chinese, however Engadget gave an in-depth summary of the launch in English.

One feature relates directly to language selection. From the Endgadget overview:

Country flags instead of text menu for language setting, so that you can easily reverse the damage if someone accidentally changes the language

In the launch, founder Luo Yonghao shows a scenario where the phone has had its language changed — and shows how the new operating system will help redress a situation like this. It’s in Chinese, but the video is easy enough to follow: and a caveat here, I don’t speak Chinese, so this blog post is based purely on the visuals shown by Luo Yonghao. The video starts by showing the difficulties users would have on various phone operating systems (Android, Windows Mobile and iOS) if they have to change the phone language back but can’t understand any labels:

It ends with rapturous applause as Luo Yonghao show’s Smartisan’s solution to this problem: a bar with flags to denote language settings.

Having a phone with a different language can indeed be extremely frustrating: I myself recently borrowed a Palm Pre from a German friend and had a lot of fun trying to find how to change the language to English. It’s a definite problem: although in practice I think in most scenarios where a phone’s language is changed into an unintelligible language it’s usually the result of a prank rather than a user mistake. (And it’s quite a good prank for precisely this reason: it’s a real pain to undo.)

While the flag icons definitely help, I don’t think they’re ideal here because they could also suggest regional or location settings: timezone, date format or currency. I think some of the approaches highlighted elsewhere on this site would work far better.

But stepping away from icons, Smartisan could actually do far better to deal with this sort of scenario — and in fact, all software designers could.

Let’s reconsider the scenario we’re dealing with here: a user who speaks language X is trying to change the language of the phone which is in language Z.

Going back to the Smartisan example, the flag icons are at the very bottom of the settings screen. A user has to scroll to the very bottom to find them.

Consider the following ideas for dealing with this problem:

Arguably the language settings on a phone should be at the very top of the settings screen: in the Android example shown first, it’s actually the third in the list.
If the language settings are not at the top of the settings screen, then after changing the phone’s language move the language settings to the top
Make the operating system remember the previous language setting and label the language selection in the previous language in addition to the current language.

For example, the current Android OS after changing the language from English to Chinese. On the left is the main system menu, and on the right the language sub menu:

You’re in for some serious guess work here if you don’t read Chinese and want to change the language.

Now using some of the above suggestions, a responsive way of dealing with accidental language changing — the labels are in English here but should be whatever the previous language was:

Would this be annoying for users who change their language on their devices? Probably not too annoying — and how many users do this anyway? Would it be useful for those who accidentally changed their language — or have been the victim of a prank? Immensely.

Flags aside, this is a much better way of dealing with language selection on all devices.

Barclays Cycle Hire language selection

Officially known as Barclays Cycle Hire, Transport for London’s blue hire bikes are a ubiquitous sight around London. Hiring a bike is fairly straightforward using the interactive kiosks located next to docking stations around the city.

The kiosks support seventeen languages: along with English, the system is localised in German, Spanish, French, Italian, Arabic, Bengali, Gujarati, Hindi, Chinese, Polish, Punjabi, Tamil, Turkish, Urdu, Vietnamese and Japanese.

The icon for language selection is a British flag:

However, this is the only flag used for language, as shown on the language selection screen below:

The use of the British flag is an interesting choice. While the system doesn’t explicitly use flags to represent languages, it does use a flag to show availability of languages.

It would be very interesting to see stats on how many users actually find and use localised versions of the kiosk. By using the British flag alone, could the system possibly miscommunicate itself?

London’s official promotional organisation London & Partners provides visitor statistics to London by nationality. The top three nations are the USA, France and Italy. This allows us to begin to understand the types of users who would be using the system.

Currency?

Looking at the top three types of visitors, could users mistake the British flag for a currency icon rather than a language icon? Payment is only available in the Great British Pound — visitors from the US may want to use US dollars or visitors from the EU may want to use the euro. (This may be either cancelled out or confused even further by the pound icon next to ‘balance’ on the home screen in the top right.)

Probably not a major issue — but it does suggest the language selection proposition represented by the British flag is not as strong as it could be.

Exclusivity?

As a visitor or new immigrant, does the British flag suggest it could be exclusively for British citizens only? By virtue of the flag being isolated here, again this is a possibility. Ironically the presence of other flags would probably negate this.

Improvement through prioritisation

Obviously the majority of visitors from United States would not need translated content. Many French, German and Italian users may have a good enough grasp of English to navigate the system without translation — so users from those countries might not use the translations as much as users from perhaps Asia or South America.

The most effective strategy for presenting translation options would be to find the balance between the group of language speakers that would benefit most from translation versus the group of language speakers that comprise the largest number of users.

Once establishing this, language selection can be based on this priority.

The new design above shows a more generic speech bubble icon instead of a flag to represent language. It also displays five languages on the home screen and a button alluding to further languages being available.

Would the above screen work better at showing language options? Potentially — of course the only true way to know would be to test this with real users.

Bab.la: flag overload?

Bab.la is an excellent online language resource with online translation as one of its core services — in an impressive 22 languages.

The site makes heavy use of flags as iconography, with some interesting flag choices: Arabic is represented by the Egyptian flag, Swahili by the Kenyan flag and Hindi by the Indian flag.

Arabic is an official language in 24 countries other than Egypt (however, Egypt is by far the largest by population) and Swahili is an official language in four countries. While Hindi is the most widely spoken language in India, there are 22 official languages in India.

Furthermore, English is represented by the Union Jack; however it is an official language in over 50 countries. Also, the United States which has many more English-speakers than the United Kingdom. (The same argument can be applied to the use of Spanish and Portuguese flags for those languages in relation to Mexico and Brazil respectively).

Regardless of whether flags are appropriate in this situation, another question can be posed: do the flags actually aid in legibility of the translation menu? Or are they actually distracting?

Consider the Google Translate interface that supports 65 languages:

Arguably the Google Translate is easier to read and far more compact on screen: and it achieves this in part by not using flags to represent languages.

LEGO.com: effective design for region and language

The LEGO website is available in 17 languages. When a user goes to select language, they are prompted to first choose their country or region and then their language as appropriate.

Belgian users have the option of French or Dutch content specific to their country; Spanish users can select Spain or Latin America as appropriate.

The use of flags here gives priority to country/region first — which is why it works. Only for Latin America is a flag not used, as it is obviously referring to a whole region and not a specific country. Language is a secondary option. In this scenario, LEGO’s use of flags works very well.

As a global brand, LEGO has registered domains in many other countries even though they do not have local content for all of them. The site does its best to redirect users to the most appropriate version of the site. Australia users visiting www.lego.com.au are redirected to the UK English site; Canadian users visiting www.lego.ca are redirected to the US English site.

As the site gives priority to country over language, this is a much better approach than just combining flags with language names.

However, there are limitations to this approach: Swiss users accessing www.lego.ch are redirected to the German site. French-speaking Swiss users may not appreciate this, but given there is no specific Swiss content available this is far more acceptable than just redirecting them to a generic German-language site. Ideally, however, the LEGO site would do better checking the language of the user and redirecting them based on that — not just the domain they’re visiting.

While it’s not perfect, the thought that LEGO has put into its user experience for international users is highly commendable.

Steam: choose language or choose country?

The Steam client is a great video-gaming platform. It allows users to buy and download games, connect with friends and share screenshots from their gaming experiences. The website is available in 24 languages, and it even has a community-driven translation project.

However, unlike the website, the Windows client has some issues with language versus location.

Steal install screenshot

The choice of Chinese Simplified versus Chinese Traditional is interesting: Simplified is the norm in mainland China, yet Traditional is mostly used in Taiwain (but also Chinese ethnic groups outside of mainland China).

But the other flag choices are inconsistent: the United States flag is used for English. Understandable perhaps as Steam are a US-based company, but a look at the Steam client stats server reveals Steam has heavy usage in other English-speaking countries such as Australia, Britain, Canada, Ireland, New Zealand, Singapore and South Africa.

While there is no data on Brazilian users versus Portuguese, by sheer population numbers one would expect Brazil to have more users than those in Portugal: yet the Portuguese flag is used for Portuguese. Again, this is inconsistent with the choice of the US flag for English.

As for Spanish, how many users are in Spain compared to Argentina, Chile and Mexico or other Spanish-speaking countries?

Are Steam really asking what country the user is in, or what language they prefer? It appears to be a confused mix between the two.

Another problem with this install process is the lack of localised names — forcing users into selecting a flag to for their language (whilst the language is labelled in the English-name for that language).

The Steam website handles translations brilliantly: each language is localised and also in English for disambiguation. And no flags.

However, their installer client needs some more thought.

Tate Art Galleries: 12 languages, 9 flags

The Tate Galleries in the UK are a word-class collection of galleries and have a great website — with the exception of the language links on the homepage.

The most interesting part of this design choice is that there is obviously a cultural awareness that flags may not properly represent the Arabic and Chinese languages — so these languages are just written in their local equivalents.

But not so for French, German, Italian, Portuguese, Spanish, Japanese, Greek, Russian or Polish.

Furthermore, the flags are repeated in the content area of the pages these links lead to: of course with the exception of Arabic and Chinese.

(It’s also worth noting the BSL — British Sign Language — link. The hand icon here seems very appropriate for this).

Another issue with the choice of flags for some languages and the language name for others is also simple consistency.

Wouldn’t this design work far better if it just showed the language names?

Simple, consistent and uncontroversial?

avaaz.org: simple yet effective multilingual content design

Social activism site avaaz.org is beautifully designed: both visually and experience-wise.

The site is available in 14 languages: each easily accessible from the top banner and presented in their local formats. Furthermore, the site autodetects the users language and redirects them to a localised version (if one is available).

A simple yet very effective way of presenting multilingual content.

The Metropolitan Police: 16 languages, 12 flags

The Metropolitan Police website provides language content in 16 languages other than English: Arabic, Bengali, Chinese, French, Greek, Gujarati, Hindi, Japanese, Polish, Portuguese, Punjabi, Somali, Spanish, Turkish, Urdu and Vietnamese. That’s quite a diverse range of content.

Met Police

From the homepage, a neat and attractive row of 12 flags links through to a landing page listing 16 languages.

12 flags, 16 languages: are some flags missing from the homepage?

Let’s follow the link and go to the next page:

Starting with the positive, each language is displayed in its native name and script (and also repeated in English).

But other than that, this is all wrong. It’s probably the single best example of why using flags for languages is so fundamentally flawed.

The biggest problem on this page is the use of the Indian flag three times for Hindi, Gujarati and Punjabi. With the former, it’s worth noting that there are actually over double the amount of Punjabi speakers in Pakistan (60 million speakers) than in India (27 millon speakers).

Saudi Arabia’s flag has been chosen for Arabic on this page, yet on the homepage the flag of the Arab League has been used.

Arab League

Saudi Arabia

Arab League or Saudi flag — is either an appropriate representation of the Arabic language?

Consistency aside, obviously there’s been some trepidation here about how to represent the Arab language with a flag. More reason, of course, to avoid using any flag for language representation.

A final gripe: the homepage flags, for their inherent flaws, do look rather nice. However, the quality of the flags on the landing page is simply awful (not to mention the poor legibility of the native language names). Give flags some respect and please save them with an appropriate level of quality!