Thursday May 22, 2014

Oracle ADF and Simplified UI Apps: I18n Feng Shui on Display

I demoed the Hebrew language version of Oracle Sales Cloud Release 8 live in Israel recently, and the crowd was yet again wowed by the simplified UI (SUI).

I’ve now spent some time playing around with most of the 23 languages, the NLS (Natural Language Support) versions, as we’d call them, available in Release 8.

Hebrew language Oracle Sales Cloud UI Release 8

Hebrew Oracle Sales Cloud Release 8

The simplified UI is built using 100% Oracle ADF. The framework is a great solution for developers to productively build tablet-first, mobility-driven apps for users who work in natural languages other than English.

Oracle ADF’s internationalization (i18n) support leverages Java and Unicode and also packs more i18n goodness such as Bi-Di (or bi-directional) flipping of pages, locale-enabled resource bundles, date and time support, and so on.

Spanish and Hebrew Simplified UIs Bi-Directional Components Compared

Comparing Spanish (left) and Hebrew Bi-Di (right) page components in the simplified UI.
Note the change in the direction of the arrows and alignment of the text.

So, developers don’t have to do anything special with regard to ADF components thanks to this baked-in UX Feng Shui, as Grant Ronald of the ADF team would say to the UK Oracle User Group.

Find out more from Frédéric Desbiens (@blueberrycoder) about ADF i18n on the ADF Architecture TV YouTube channel and check out the Developer's Guide.

Wednesday Jan 19, 2011

Designing Global Graphics in Enterprise Apps: Points to Consider

Continuing my series on translatability for UX professionals in the enterprise applications space, let's look at graphics.

The essence of designing a global graphic is simple: aim to create an image file that requires no subsequent intervention by developers or translators to make it suitable for any other language versions. Use these guidelines:

  • Design an image file that has no translatable text on it (including single letter such as B for Bold or whatever). The file should be used for every language version's UI without any further work on it.
  • Avoid graphics that might present cultural issues in the translated version. Use generic icons. Be wary of designs that use body parts such as hands or feet, pictures of people, relies or a visual pun. Avoid flags for languages.

    There are lots of possibilities of things to avoid here, usually recommended by people who don't work in the enterprise applications space but on global web sites. If you're using crucifixes and pictures of pigs in an enterprise app UI, you're probably going wrong anyway. Common sense please!

  • Use web-safe colors, but don't worry too much about overblown cultural issues about colors in the enterprise applications space. It's not like anyone will log a bug saying white and not black is the color of mourning in Asia, ignoring the coffin icons you've used for the Exit menu option (who ever does that?). Colors generally are only problematic when associated with objects, and not in their own right.
  • If using arrows or pointer image files in the UI, then make sure you create equivalent files with reversed directions so that they will work with bi-di  language versions of the applications. Although browsers can mirror HTML UIs based on DIR (directional element) or locale preference settings, they cannot flip binary objects such as image files.

    So, create an right-to-left (RTL) equivalent for any left-to-right (LTR) directional image, give it an "rtl" (for right-to-left) filename suffix and work with your developers to implement code to use the RTL image when the detected user's language is Hebrew, Arabic, and so on. And it test to ensure that it works. Here's an example:

LTR version arrow points to search icon (correct)
How LTR version arrow points away from search icon in bi-di language version and towards an data entry field instead (incorrect)
How RTL version arrow points to search icon in bi-di language version (correct)

Use these guidelines for graphics that might require translator intervention (usually these are in user assistance components):

  • If there is translatable text on a graphic, then make sure the image has enough space to allow the text length to expand. Don't use abbreviations or acronyms on the image as a way to save space.
  • Supply image file format, font, color, line weight, and screen resolution information to the translation team so the translated image will have the same rendering and look and feel as they source image.
  • Create the image files in tools that support Unicode fonts so they will work for all languages.
  • For conceptual images, diagrams, and so on in user assistance deliverables, use an editable source file format that can be easily redrawn if necessary during translation, for example Microsoft Visio VSD format.
  • If using Adobe PhotoShop, supply the translation team with the PSD layers along with the final output format for comparison (PNG, JPG, or whatever).
  • If you've sample data shown in a spreadsheet or database table then provide the source files so the data can be localized easily too.
  • Avoid placing screen shots in documents. Use a tool like Oracle's User Productivity Kit  to easily recapture translated screens and to automatically translate UI widget names and actions. 

You might investigate the possibilities offered by SVG and XLIFF in the hope of making savings for graphics translation. Investing effort in transforming files to SVG, XLIFF, or any other XML format is not worth it relative to the cost of doing graphics the old way in my opinion (say where the cost is probably less than 5% of total translation cost). Defining and enforcing translatable elements in SVG is a pain and if a graphic requires redrawing after translation, then SVG is not worth it. Suck it up.

Do you have any other guidelines for designers working in the enterprise applications space? Find the comments.

(Incidentally, after I wrote this, I looked up my article in Multilingual Computing and Technology Volume 9, Issue 5 called Creating Easily Localizable Graphics  published in August, 1998. Still seems quite sensible!)


Oracle Applications Cloud global user experience (UX): Culture, localization, internationalization, language, personalization, more. A globally-savvy UX making it all fit together for Oracle's worldwide partners and customers.

Audience: Enterprise applications translation and localization topics for the user experience professional (designers, engineers, developers, researchers)!

Ultan Ó Broin. Senior Director, Oracle Applications User Experience, Oracle EMEA. Twitter: @localization



« July 2016