Skip to main content

Designing a World-Ready Program

Customizing Features

The process of writing a specification that's oriented toward world-readiness will, among other things, force you to think about what features will need customizing. Of course, a well-designed, world-ready core product minimizes the need for customizing features for different language editions.

On this page

Designing an International User Interface that is LocalizableDesigning an International User Interface that is Localizable

Researching Legal IssuesResearching Legal Issues

Keeping Features AccessibleKeeping Features Accessible

Market CustomizationMarket Customization

The process of writing a specification that's oriented toward world-readiness will, among other things, force you to think about what features will need customizing. Of course, a well-designed, world-ready core product minimizes the need for customizing features for different language editions. As you write your product specification, however, you might find that certain features important to your domestic market don't make sense for other markets, or that some markets require functionality that isn't necessary for your domestic market. For example, the East Asian versions of Windows XP automatically add the necessary IMEs at installation, whereas the English version does not, but instead allows the user to install them later if needed.

Some features might be essential for all language editions of a program, but they might require that different code be executed for different languages. One obvious example involves features that do lexical analysis-spelling checkers and grammar checkers, for example. Spelling rules and common words change from language to language. Therefore, most Windows-based software products ship spelling engines as separate DLLs and spelling dictionaries as separate compressed files. For some languages, such as Italian, spelling rules are simple and consistent. For others, such as Japanese, spelling checkers and grammar checkers are exceedingly difficult to write.

Another example of feature design that is locale-specific involves the Regional And Language Options component of Control Panel in Windows XP. While the Sorting tab appears in the Customize Regional Options property sheet of some language versions, in others it is absent, depending on the particular language's rules regarding word sorting. For instance, some regions like English (United States) or Italian (Italy) have only one way to sort words in some prearranged order. Other regions like German (Germany), Spanish (Spain), or Simplified Chinese (PRC) have more than one way. Thus the Customize Regional Options property sheet displays the Sorting tab only when the region's locale has more than one sort order, such as in the German locale, which has two different sort orders (Dictionary and Phone Book). (See Figure 2-1.) Since Italian has only one way to sort, the property sheet for the Italian locale does not include the Sorting tab.

The Customize Regional Options property sheet for the German (Germany) and Italian (Italy) locales.

Figure 2.1 - The Customize Regional Options property sheet for the German (Germany) and Italian (Italy) locales.

In cases such as those just discussed, it is important to create code that is flexible, so that you can easily add, remove, or customize functionality. This is especially true since your product will face tough competition in well-established markets. In Germany, for example, word processing programs with poor hyphenation engines tend to sell poorly, and in Japan, people will buy only the text processing programs that make it easy for them to enter kanji characters. Arabic speakers might expect the ability to juxtapose Arabic and English text.

Features that access large amounts of language-specific data can use text files to simplify customization. Windows Setup, for example, reads from text files the list of shipped components along with their localized file names, file sizes, and floppy disk locations. Localizing the Setup program for Windows, then, is only a matter of translating the program's user interface and tailoring the text files. The core setup code works for all language editions. Many spelling checkers use a similar mechanism. The code that searches for spelling errors and suggests corrections remains constant, but special dictionaries-such as medical, legal, and scientific dictionaries-are provided in separate data files.

Designing an International User Interface that is Localizable

By now you have seen that creating world-ready applications produces versatile applications that can be used in many different locales, thus giving you access to more markets and increased revenue. Another reason for creating world-ready applications is to keep localization and development costs down, with localizability of the UI being one of the best ways to accomplish this goal. Though both globalization and localizability are part of world-readiness (which, along with localization, forms the basis of creating internationalized software), it's important to understand the distinction between the two.

Take, for example, the executable Wordpad.exe. Making sure users can edit any supported script using different keyboard layouts and IMEs - or displaying calendar information that's specific to a particular language when users insert the date in WordPad-is part of globalization. The product does not need to be translated into a given language for users to leverage these functionalities and for testers to test these features.

Now, suppose you want to translate WordPad into a given language. Making sure that all resources that need to be translated are separated from your source code, and that dialog boxes are designed in a way that can accommodate text expansion, are both localizability considerations. Since globalization deals mostly with the application's functionality and not its user interface, defects pertaining to it are easy to detect early in the design process before any translation even starts. However, these defects require you to address potentially major changes in design or extensive coding changes. Localizability issues, on the other hand, are harder to detect. The software first needs to be either code-reviewed or be translated into either a pilot language or a pseudo-language. Also, sometimes issues only affect a given language, so you will need some extensive language-specific testing to unveil certain problems or bugs. On a positive note, localizability defects are usually relatively easy to fix, assuming that it's not too late into the design process to make such changes. Things can backfire, however, if you wait too long to address bugs, since you will then need to correct them in every language version you ship.

When designing for localizability, remember that it is human nature to take for granted that which is comfortable and familiar to us. For example, linguistically speaking, many grammar rules of our native language, which we learned intuitively when we were young, tend to reside in our unconscious mind. We usually activate or use these rules also somewhat unconsciously, rather than with our conscious, analytical mind. Similarly, it can be tempting or easy to assume that, for example, the idiomatic expression that something "costs an arm and a leg" will be similar in other languages. However, in Spanish, the same expression is that something "cuesta un ojo de la cara," or literally, that something "costs an eye from the face." In similar fashion, with languages in applications, it can be easy for developers to lose sight of how these languages will function in another language market, unless they consciously analyze the issues beforehand. Many developers create coding tricks that they feel are clever in the earnest attempt to save work and money, yet which often overlook the broader context.

Some of these programmers' tricks include the following:

  • Hard-coding strings in their code, to avoid having to create a resource handling service.
  • Saving storage space by using text strings that are concatenations of phrases. For example, developers might use the text string "The [flood gate/control rods/exit door] cannot be [closed/open/reset]"-which doesn't account for changes in verb form resulting from nouns of differing gender and number-instead of having to create nine different sentences.
  • Overlapping controls of the dialog box (such as hiding one button behind another), thus saving display space in the dialog box.

Although these strategies can be viewed as clever in that they can save some work for the developer, in the long run these myopic practices will increase costs when you localize your applications. This is because every code change that could have been avoided with good localizability practices is multiplied by the number of language markets for which you are preparing your applications. For example, if you're going into 24 markets, the cost of every localizability issue not addressed in the core code costs you up to 24 times its original cost to fix, because you might have to fix it in every language version. Localizability Overview, Isolate Localizable Resources, String Handling and UI Considerations discuss the many areas you need to think about when creating a localizable user interface.

Top of pageTop of page

Researching Legal Issues

Another component of customizing for international markets entails investigating pertinent legal issues. As you get feedback on your product specification, solicit advice from people familiar with the law in local markets. Certain kinds of features might affect the international distribution of your product. For example, some countries have export and import laws that govern the sale of products that contain encryption algorithms, such as those used for file compression or copy protection. Software that connects with telephones can be more difficult to sell in Europe, where some governments closely regulate the use of phone lines. Software and documentation that is marketed in France must be in French, and software marketed in Brazil must support hardware that is developed locally.

In Germany, competition law severely restricts a company's ability to claim that its product is better than another company's product. This directly affects advertising and packaging, but it can also affect sample files, documentation, Help files, or features that assist users in transitioning from a competitor's product to your product. Productivity features, such as those that keep track of how long a user has been editing a document, might conflict with labor laws.

Another important legal consideration is, of course, software piracy. Microsoft works with the Business Software Alliance (BSA), located in Washington, DC, to protect its products overseas. The BSA conducts educational campaigns and lobbies governments for tougher piracy laws. The efforts of the BSA have proven more effective in preventing piracy than adding copy-protection code or hardware devices to products. Although counterfeiting is illegal in many countries, some countries still allow local companies to market clones of software products. Before you enter a new software market, research these issues. Keep in mind that entering new markets requires diplomacy. Microsoft's well-publicized efforts to establish Windows in mainland China is a good case study for any company seeking to expand its operations. Microsoft was not aware of the politically sensitive issues of developing products offshore for import into the People's Republic of China when it began developing and marketing the Simplified Chinese edition of Windows. As a result, the company unwittingly angered the Chinese government. For this reason, Microsoft worked very closely with the Chinese government and local developers to ensure the full success of Windows XP.

Top of pageTop of page

Keeping Features Accessible

The purpose of making your software world-ready is to make it easy for as many people around the world as possible to use it. Designing for accessibility has the same purpose-and many features that place software within reach of people with visual, aural, cognitive, or mobility impairments also help prepare it for localization. For example, dialog boxes with a simple design and minimal text are easier to translate and easier for some people with visual impairments to read. Addressing accessibility issues in your product specification will result in a product with a larger potential worldwide market. Just as with world-readiness, designing your product to be accessible from the start saves you from having to redesign it later-and possibly from having to release special editions.

Detailed guidelines for designing accessible applications for Microsoft Windows are published in the subtopic titled "Accessibility" in "User Interface Design and Development," available in the MSDN Library.

Top of pageTop of page

Market Customization

If you want to take a product to a new level of user experience and excitement, consider market customization. With market customization you tailor your product to a specific market or user group, enhancing their experience and increasing their satisfaction.

As usual, you design the product to meet basic requirements and to perform global functions as you envision in your specification document. Then you initiate a review for market customization where you examine the experiences and features that your product offers and determine how each can be customized to feel more familiar to target users or to be more relevant for target markets. Could a feature be added or enhanced to better serve users in a certain market? You will need to have an understanding of the preferences, passions and interests of the users you are targeting, whether it is by country or region or by age and hobbies.

Market customization can vary in degree:

  1. Customize visuals and user settings: In addition to localization, the content of the product can be adapted for a given market or a group of users. Make your product automatically configure its look and feel according to users' home country or region as defined in their user locale in Windows XP or Windows Vista.
  2. Create a new component or application: An educational program teaching children how to spell in English has universal application. If the program is world-ready, it can be adapted to teach French, Chinese and many more languages. You just need to plug in the appropriate content for the language or market.

These are some advantages of market customization:

  • Satisfy unique customer requirements or needs in an efficient manner using existing project framework and infrastructure.
  • Get different pricing models in different markets without fear of grey market imports.
  • Build loyal customers who are passionate about your products and are willing to praise them to their friends and family.
  • Enhance your company's public image: By delivering applications that are customized, your company will be perceived as a local company with local talent dedicated to the success of the local economy.

As an example, let’s say you are designing the next game of Poker and you want to tap into China. Instead of just translating the text in the game from English to Chinese, try researching local card games in China. Use the engine you are building for your home market and adapt it. Customize the look and feel of the game by changing background colors and more card backs—red with images of tigers or dragons and making the king card appear in an emperor's costume are a good start. Package the game and name it in Chinese. If you do everything right, your product will have greater chances of succeeding in China than simply selling a game based on your original concepts.

Organizing a Product Team Organizing a Product Team