Software localization

Making local versions of a software requires to adapt both the language and the culture of a particular market. Most people would not care that the software they are using have been developed in Finland or in Japan but they would expect a software that gives them the impression as if it was developed not only in their native tongue but also in their own culture.

Let's imagine an educational software for children where a young character drinks a lot of coffee. While many parents in Brazil might find that behavior absolutely natural, most parents in the United States probably will not. Thus if you want to sell your localized product in the US market, you might want to replace the coffee with some kind of soft drink. However, in a localized version for the European market, soft drinks might not be the best choice either, since many European parents consider coffee and soft drinks to be equally unhealthy for their children. Likewise, avoiding sensitive geopolitical issues is another important consideration to make sure a software is well received in the international market.

Obviously, localization includes a lot of translation: text, menus, dialog boxes, buttons, wizards, online help, etc. However, beyond merely translating the language, we should also consider that currency, address, number, and date formats need to be changed as well. Besides, for many Asian languages the fonts and the font size have to be changed and Arabic or Hebrew require right-to-left layout of not only the text, but of the whole user interface. As a result, localizing a software requires to support culture-aware features right from the start. 

A localization strategy that is well planned and executed will improve the success of a localization project. The initial software specifications should consider localization as part of the product cycle. 

Delaying localization to the end of the cycle can delay the shipping date because of any unexpected localization problems that require code changes. It will also increase the cost of the project as the defects will be more difficult to correct later on.

Mobile app vs. mobile website

Source: xkcd.com

In 2014, people are spending more time on internet through mobile devices than desktop computers. Most companies have understood this and try to establish a mobile presence for their business or organization. However, navigating the options for going mobile can be tricky. Deciding between a mobile application and a mobile website is a difficult choice to make since both options present advantages and disadvantages.

The obvious solution to this dilemma would be to create both in order to capture the attention of the entire mobile audience. Nevertheless, few companies can afford to build both options and that's why it is important to discover which one is the most suitable.

Advantages of a mobile website

• More affordable: Developing a mobile website is considerably less costly than developing a native application, especially if you want to be present on different platforms (iOS, Android,...).
• Better visibility on search engines: Mobile websites are as easy to find as regular websites because their pages can be displayed in search results. Native apps cannot be crawled by search engines and their visibility is dependent of app stores.
• No need for approval: Creating a mobile website does not require to follow extensive guidelines nor to wait for the approval of an app store that can take from a week to several months.
• Better flexibility to update: Changing the design or content of a mobile website simply requires to publish the edit once and the changes are immediately visible. On the other hand, updating an app requires to go through the same approval process and users need to download the update.
• More accessible: A single mobile website can reach users across many different types of mobile devices. Its capability to reach users is far greater than a native app.

Advantages of a mobile application

• Can use smartphone functionality: A native app is the best option if you need to access a user's camera, GPS or any other phone functions.
• Better personalization: Since a native mobile application is always tied directly to a user's device, it creates more opportunities to offer a personalized user experience.
• Handle a complex UI better: Native apps provide the most tailored user experience. In particular, it's almost always the best choice for interactive games.
• No connection required: Only an app can provide an offline access to content and perform functions without a network/wireless connection.
• Easier to monetize content: With an app, it’s particularly easy for users to make a purchase with pre-entered credit card information. An app is the best suited for offering micro-purchases for products or services like buying virtual goods or access to additional content.

Generally speaking, a mobile website should be considered the first step in developing a mobile web presence. Most programmers can handle the technologies behind it and the cost difference between the two options is pretty compelling. I think that a native mobile application is the right option only for a very specific purpose that cannot be effectively accomplished via a web browser.

The reasons behind Clippy’s massive failure

Users do not like to feel trapped by their computer. This aspect makes user control one of the most important interaction design guidelines and Microsoft learned this lesson the hard way with their Office Assistant debacle.

In the 90s, Microsoft decided to improve human computer interaction using sophisticated mathematical methods. The company's objective was to provide valuable assistance and feedback to users when necessary. This desire was materialized for the first time in Microsoft Office 97 by introducing an animated character that would guide users while they use Word and Excel. The default version of this interactive character was a talking paperclip named Clippy.

Unfortunately, Clippy worked so poorly - by trying to help when no help was needed - that it was not long before users started complaining about its behavior. For example, if you typed "Dear X" in Word, Clippy would pop up out of nowhere and say "It looks like you're writing a letter. Would you like help?".

Many users felt Clippy was a very annoying nuisance which hampered their experience of the office tool by continuously disrupting their workflow. This point of view was so widely spread that it was the subject in 2003 of a Stanford student thesis entitled Why people hate the paperclip: labels, appearance, behavior and social responses to user interface agents. A major fault that the tool had was that that it could not reason about user competence. An experienced user, who would find the tool useless, could not be differentiated from a novice user for whom the tool could be necessary. According to the blog Robotics Zeitgeist, this user differentiation feature existed but was excluded of the product release because of a lack of disk space.

Eventually Microsoft understood that their little animated character has been despised globally that they themselves started to tease him. Microsoft turned off Clippy by default with the release of Office XP on 2001 and the Office Assistant was completely removed in Office 2007.

In 2010, Time magazine declared Clippy one of the 50 worst inventions of all time. More recently, Clippy made the buzz by opening a Twitter account where he called out Satya Nadella, the recently promoted CEO of Microsoft Corporation :

You do know what tomorrow's Microsoft event is about right? @satyanadella is bringing me back, baby!
— Clippy (@ClippyTheClip) 27 Mars 2014

@ClippyTheClip nice try buddy :)
— Satya Nadella (@satyanadella) 27 Mars 2014