2012-02-21

Mr. Invalid Character

Introduction


I finally received new laptop at work. It's a brand new MacBook Pro. It should not be very surprising that one of the first things I wanted to install (and try out) was XCode. The only problem is, XCode is available through App Store. Therefore I had to create an Apple ID.

To be honest, I wasn't expecting so many internationalization defects in such a simple application. I thought it is not that hard to create simple registration form... Well, I was wrong.

Birth Date


The first thing that caught my eyes was birth date selection. I don't know why Apple needs to know my birth date in the first place, but that's not the worst part.

The worst part is, they assume everybody uses Gregorian calendar. I am not so sure if I knew my Gregorian birth date, if I were Russian (for example).

Another issue is, rather then simply enter the day, they force me to choose it from a drop-down. With 31 items, it is not too easy to select the right one and to be honest, I really dislike it. Apple is known for their Usability, but to me this is clearly a mistake.

Billing Address


For no apparent reason, Apple requires billing address, even if I select "None" as a payment method:


I wouldn't care so much but their registration form is full of i18n defects.

The first thing you might notice is title. It is required. You want see it on the screenshot, but there are only few title you can select. This is wrong, as titles surely depend on the culture. Personally, I prefer no title at all and I feel a bit offended if somebody call me this way.

Another thing, it seems that only ASCII characters are accepted in Personal Name fields and Address fields. Dear Apple, my name is Paweł. Like it or not, this is my name. And I don't want it transcribed into Latin alphabet.
The street name, where I work also contains Polish diacritics. It is very interesting idea to expect street names would be written in Latin all over the world.

Last, but not least: Apple expects everyone to have a first name and the last name. The problem is, this also depends on the culture.

That's all folks.

Thank you for registering, Mr. Invalid Character!

2012-02-17

Language switcher drop-down anti-pattern

Note: This post is related to User Experience (UX) and Internationalization. I am focusing specifically on web applications. Please keep in mind, that there are specific use cases were Language Switcher make sense (this especially regards to static web pages.)

What is a Language Switcher?


By "Language Switcher", I understand the facility that let you change current language of the application. By "Language Switcher drop-down", I mean drop-down menu (aka combo box, aka pull-down menu) that let's you choose and change active User Interface language, placed somewhere on the every page (as oppose to being placed on the preferences page only).

Why I decided to write this post


It seems that more and more people think of using Language Switcher drop-down nowadays. To make it worse, the usage patterns seems not to be limited to static web pages (the original use case for this mechanism), but it is more common to see Language Switcher in desktop or mobile applications.
I am not going to dive into details why it is not a good idea to even think of Language Switcher in the latter case, but please answer this question: "I have already chosen the User Interface language for my device, why do you bother me to make a choice again?".

Please let me know, if you have good answer to aforementioned question. However, please be warned that I am going to accept objective answers only. "Because I sometimes want to see an application in different language" is very subjective and does not add anything to the discussion.

Language Switcher drop-down pros and cons


Let me list specific pros and cons of using Language Switcher drop-down. If you can think of more examples, do not hesitate to post a comment.

Pros of using Language Switcher


1. It is very easy to change the language.

That's really indisputable, even rather inexperienced user should be able to switch language, provided that (s)he will be able to locate the Switcher and understand its meaning (see cons below).

2. It is fairly easy for technical support engineers to troubleshoot foreign language users problems.

Let's imagine following problem. The Chinese speaking user has technical problem and needs help of non-Chinese speaking support technician. Support engineers logs in to the Chinese user machine remotely and navigates to your application. As (s)he does not speak Chinese, there is a need to switch language in order to troubleshoot the problem.
In such case Language Switcher drop-down (see prior point) is really great solution. Of course other solutions to the problem might exist, but none of them is as easy to use.

3. Sometimes users log in from a public computer (configured for another language).

This use case is usually listed as number one when we talk about static web pages. However, in context of web application, it is not necessary as strong pro argument.

Of course that is true, that if you do not preserve language selection in the right way (that is other than a cookie or a Local Storage), Language Switcher is probably a must.

But then again, you really should persist this setting.If you do, the only area where you might face is language selection problem is a new user registration.

However, it is very bad idea for users to register from public device.

For starters, the device might be full of spyware, trojans and keyloggers and you surely don't want your users to take that risk. Therefore, it might be actually better for users not to understand what's going on - in this case they will probably give up before disclosing sensitive information about themselves.

Cons of using Language Switcher


1. Language Switcher is sometimes used as an excuse for not implementing proper Language Negotiation.

Some people think that detecting and selecting appropriate language from HTTP Accept-Language header (that is what any modern web browser sends along with HTTP request) is too hard.
They might say: we implemented Language Switcher, so what's the problem if application is in English?
The problem is, most of the world population does not speak English. According to Wikipedia, only around 1.5 billion people out of 7 billion total speak this language.

The very fact, that you decided on localizing your software (otherwise implementing Language Switcher would be pointless) means that you somehow care about these people.
Therefore you really need to detect the language from web browser (you at least need to set some reasonable default) and using Language Switcher (in any form, not just drop-down) is no excuse.

I add this as an argument against, because it is raised surprisingly often. OK, it is not as important one as others, so please read on.

2. Web browser's default language is valid for most of the users.

Most of the time, web browser will be set user default language taken from the Operating System. That's the reasonable default.
Firefox uses different approach - its language will be set to Firefox distribution language, that is Chinese Simplified version of Firefox will sent "zh-CN" as user's most appropriate language.

Therefore if you are Chinese user living in US and you are using English OS, you have two choices; either switch your default web browser's language or install Chinese version of Firefox (this points to Windows version, but you can find any language and system version here.)

On the other hand, most web browsers lets you change your preferences (Safari is unfortunate exception.) It is really not that hard. Of course that would be problem for computer illiterate, but I don't really think Language Switcher would resolve that issue (see below).

3. Implementation of the Language Switcher raise many technical problems.

On the technical side of things, implementing Language Switcher is not the easiest (and not the best) thing to do. That's because of few facts:

  • Most of Web Frameworks are not designed to handle language switching
    • That means problems with refreshing the User Interface with new language values - this regards to translations obtained from resource files, but... See below;
    • If you have some controls in your application UI that are bound to a database or a web service, chances are hight that you will have to close the connection and re-open it with new Locale (not just the language). This will cause considerable amount of coding effort;
    • In most cases you would need to create logic for reading the translations manually as oppose to use default framework mechanism (in case of Asp.Net that means that you'll be forced to use Explicit Localization mechanism as oppose to Implicit Localization one.) That's another few (hundreds) lines of code that could possibly contain defects,
  • Language is rarely the part of Domain Model
    • If you use Model View Controller or Model View Presenter design pattern, language will either pollute your domain, or you will need to violate Single Responsibility principle if you let Controller or Presenter take care of language switching;
    • If you use Model View View Model pattern everything should be fine, but you might run into problems like not being able to switch language (that really depends on the framework used.)
  • It's not too easy to persist language change
    • The easiest way to persist language change is to store it in a cookie or to save it to Local Storage;
      • That method works well for single device users only
      • Cookies might expire or be deleted
    • Storing it to database pose problems
      • As language is not part of a domain model, you would need to tightly couple your business classes to user preferences (i.e. put language preference to the Model)
      • Alternatively you would need to maintain separate Model (possibly with a separate database connection) to store only the language preference and tightly couple it to each controller (does not really make sense, does it?)

I hope you will agree that it means a lot of work and considerable amount of code which might fail. At the same time, the quality of the code will be lower than desired (due to unavoidable tight coupling).
It might be a problem to maintain the code should your application evolve.
And as we know, applications do evolve. Unless your application is useless, people will request new features, or the business problem it solves will evolve requiring you to make changes.

4. Implementing Language Switcher drop-down means a lot of testing.

There is no way to get away from this; put Language Switcher on every page in your application and you will need to test it. For each and every page. Of course, you can implement automated tests (using Selenium for example), but this will be quite an effort.

5. It costs a lot of money.

Because of technical difficulties with implementation, as well as serious amount of testing required, it will cost you a small fortune to implement Language Switcher drop-down feature.
The sheer amount of code required to implement it, will cause defects. That's because people are not robots and do make mistakes.
As I said, maintaining the code will be problematic (due to tight coupling). Problematic also means more costly.

6. Language Switcher might result in cluttered User Interface.

From the User Interface design perspective, the best UI is a simple one. You should really avoid placing too many controls.
Simple designs are usually much easier to use and often results in more successful products. Simplicity sells.

I hope your company's application really looks closer to the the Apple or Google products:



With Language Switcher (especially not in drop-down form) the Interface of your application might be crowded.

And because of the basic fact, that translated texts are usually longer than English ones, it might be very hard to maintain the desired look and feel.

Do not overcrowd your Main User Interface with Language Switchers and other unnecessary stuff.

7. There is no placement pattern.

Continuing on UX front, there is no really meaningful design pattern which dictates where you should put your Language Switcher drop-down.

I would expect it somewhere in the upper right corner of the page (for languages written from left to right) or in the upper left corner (for languages written from right to left).

For languages written vertically, I really have no basic idea where to put this control.

You decide:


Which is better: a), b) or c)?

This problem is not just hypothetical; if there is no placement pattern, chances are high that your users will have trouble locating and using the Language Switcher.

By the way: In YouTube Google placed Language Switcher drop-down, together with country selector in the footer of the page. Personally I don't think that many people will even notice it.

8. There is no reasonable way to highlight purpose of the Language Switcher.

Although Language Switcher drop-down is getting more common, it is still uncommon enough that you need to make its purpose clear to users.
This is especially the case, when user sees User Interface in the foreign language.
Many of them won't be able to understand the meaning of the language name and the purpose of the Language Switcher.

That's exactly the reason why many designers tend to highlight the language switcher using flags correlated with a language (the example shows simple switcher, but people use flags for drop-downs too):


I am sorry to let you know, but this is a design mistake on its own.

For starters, flag identifies a territory, not the language.
So what you would do, use the largest country flag, or the country from which the language originates from?
If you do that, several people will be offended. That's because, there quite a few countries with an official language of its former occupants (or other complicated history that makes them unhappy with the flag selection.)

On the other hand, there are surprisingly large number of countries with more than one language. What you would do if your application were to support Hindi, Bengali and Telugu? Would you put and Indian flag next each one of them?

Also, please keep in mind that there are several countries that uses the same flag.

How do you handle language variants, i.e. Norwegian Bokmål and Norwegian Nynorsk?
Reusing the flag does not sound as very good idea to me.

Last, but not least, flags will not be helpful for color-blind people.

These were the reasons why Microsoft used language identifiers to highlight the purpose of the Keyboard Switcher in their MS Windows OS. But then again, language identifiers like "de", "en-US", "pl" and "zh-Hans" are meaningless for most of the people.

Without proper highlight (and there is no way to do it), Language Switcher will be ignored by the people who needs it most - the ones who don't really know how to change web browser's preferences.

9. It is hard to organize the menu with large number of languages.

With large number of supported languages, the classic drop-down design is too crowded to be useful. You need to somehow split it into groups (for example by geographic regions).
However, that poses another issues, the most prominent one is how to split it. If you decide on splitting it geographically, you might need to put one language to several groups.

Choosing the grouping scheme will give you a headache. Below is how Google did on YouTube:


Apart from few bugs (like writing Polish language starting with capital letter or incorrect alignment of languages written Right to Left) it is designed pretty well. Just imagine you have all that languages in a single list...

10. The Language Switcher doesn't really belong to Main UI.

The language is a preference. Just like in case of any other preference modifiers, the place of Language Switcher is in user profile (along with other preference mutators).

It is hard to dispute with this argument; you won't put email settings on each and every page, you won't put time zone or date preference to Main UI and so on.

User preferences have their place in the user profile and desired language is not really an exception.

Summary of pros and cons


As you probably see, cons outweigh pros. That's exactly why Language Switcher drop-down is an anti-pattern.

However, please keep in mind that like with any other design pattern, there are several cases, where the pattern could be anti-pattern and vice versa. In most cases you really should not bother with Language Switcher implementation, but there might be specific business case where it is needed. Just like case of any other UX pattern, you need to conduct user studies to better understand how users interact with your application.

I focused on web applications, but in case of desktop and mobile applications the reasoning would be very similar. In most cases, you should not even think of implementing Language Switchers - Operating Systems have Locale settings for a reason.

At the same time, please keep in mind, that Language Switcher might make a lot of sense in the context of static web pages. You won't usually find user profiles in such case and the contents of the web page might be different depending on the language.
Again, knowing how your users use your web page might be important factor in decision making process.

What to do instead?


Here is what I would do:

1. Move language switcher to user profile (preferences page), where it really belongs.

I don't think that we need special exempt for Language Switcher, this is a preference and it should be placed along with other Regional Preferences such as Date & Time format, Number Format, Time Zone and Sorting Order.

How to design Regional Preferences page is another topic, which I hope to complete soon.

2. Redirect user to preferences page on first log on.

In case of Enterprise Applications, user account will be usually created by System Administrator (either manually or with aid from some script). That's why I suggest on redirecting user to preferences on first log on.
That way, user will be able (or even forced) to set valid preferences.

Of course, you need to provide valid default, that is guess language settings from HTTP Accept-Language header and guess time zone from web browser (the UTC offset might be the part of login form as a hidden field set up by simple client-side script.)

3. Implement URL parameter language override.

To help poor Technical Support Engineers switch language when they really have to, one could implement HTTP Filter that will read URL and set override language settings when certain parameter is present in URL, for example this URL:

http://your.application.example.com/something?lang=en-us

should switch language to English (United States).

4. Have global language preferences for all your applications.

I would suggest on having global user profile, so that users do not have to modify their setting over and over again. However, that pose another design challenge: what if some of your applications are localized into smaller set of languages than others?

The only way to resolve this, would be to have list-box of preferred languages, just like web browsers do.

Your turn...


...to make a point. Post a comment. Objective arguments only, pretty please!