A Developer’s Guide To User Experience In App Localization

More documents

Recommendations

Info

A Developer’s Guide To User Experience In App Localization French (almost three times as many characters. Clearly, trying to squeeze all these extra letters into a space tailormade for the shortest version will cause problems with display and layout, usability, and therefore UX. Minimum font sizes that work (just) with languages like English may make other more complex language characters unreadable: 漢字 , for instance. Additionally, line height used for English or similar Western languages may be too small for Chinese and other languages needing greater line heights. Whatever the font size or line height, the characters for any localized language must be readable. This may mean increasing minimum values for all language versions, or possibly using different layout criteria for different localizations (see below.) Double-Length Pre- Or Pseudo-Localization To Find Problems Word length problems caused by volume expansion as in the English/German/French example above can be detected by making a double-length version of separated text strings and displaying this double-length version. Text overruns will be much more obvious. However, for app localizations that lead to volume contraction (English to Chinese, for example), the services of a native speaker with an eye for layout may be indispensable to identify where too much blank space is being generated and where fields, buttons, or layouts may need to be modified. If your app runs on a PC or via a PC browser, using a keyboard, watch out for hotkey or macro-style key combinations that may not be available on keyboards for other languages. You may find it better to use function keys (F1, F2, F3, etc.) which are often available no matter which keyboard is being used. Alternatively, avoid this kind of hotkey functionality from the design stage onwards. Handling App Localization UX Issues Caused By Layouts A localized version of an app can lead to unsightly changes in layout, even when automatic adjustment is used (like Auto Layout in iOS.) The examples in the previous section indicate why this can happen. A layout that lined up nicely in the default language may become distorted as phraseapp.com | sales@phraseapp.com | +49-40-357-187-76 | twitter.com/phraseapp | facebook.com/phraseapp | linkedin.com/company/phraseapp
A Developer’s Guide To User Experience In App Localization it struggles to display foreign language equivalents. Efforts to standardize on one set of dimensions for a language with medium space requirements may not work either, especially when volume expansion and contraction can double or halve text lengths, respectively. The best solution or compromise may be different in each case. It is likely you will only recover a reasonable UI and UX that works for different localizations by trying different options and getting native speaker input. However, some options might include: ● Using dropdown menus to disguise length differences (this may lead to more clicks/taps being required, thus degrading usability) ● Dynamic layouts that display longer texts on two lines instead of one (visually, this may look inconsistent between different localizations) ● Programmatic changes to layouts, driven by the language or locale (country/language combination) of the localization. This is a possible solution to the changing number of name fields between different localizations – See the “Don’t Make Users Think” section above. Right To Left And Left To Right Displays Right to left (RTL) languages such as Arabic and Hebrew not only change the direction of text compared to English, for instance, but they also change notions of time and sequences of actions. RTL native language speakers may therefore expect to see a “trash can” on the left of the screen, rather than the right, because that is where they naturally end up before taking a final action to throw something away. Similarly, “next” and “back” buttons will logically be on the left and the right, respectively, instead of on the right and the left, as in English language screens. In RTL displays, time runs from right to left. Watch out also for icons used to indicate functions such as text justification. They too will need to read from right to left, for example, with a “ragged left” icon, instead of a “ragged right” one. App interfaces that are highly dependent on lateral movement to make their logic and user experience work properly for LTR languages, may need to be rethought and redesigned for RTL languages, if the same quality of UX is to be achieved. This is yet another aspect that is best handled in the initial design phase, rather than trying to change an existing app. Sometimes you will not have the choice. However, if you are in the fortunate position of starting to design a new app, you can take these aspects into account, according to the different localizations you think phraseapp.com | sales@phraseapp.com | +49-40-357-187-76 | twitter.com/phraseapp | facebook.com/phraseapp | linkedin.com/company/phraseapp
Page 1 and 2: A Developer’s Guide To User Exper
Page 7: A Developer’s Guide To User Exper
Page 13: A Developer’s Guide To User Exper

A Developer’s Guide To User Experience In App Localization

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?