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.

Friday Aug 26, 2011

Internationalizing Designs and Usability Testing for Enterprise Apps: Points to Consider

User experience is global, and usability research and testing must involve real applications users doing realistic tasks in all of Oracle's target markets worldwide. However, creating designs and prototypes for every language that Oracle translates its applications into (30 plus) is neither feasible nor required. Here's some guidance about creating lo-fi designs, prototypes and testing scenarios that will work well internationally, make the target audience comfortable, while obtaining relevant feedback on materials.

The Reality...

Optimally, the user experience shown in designs, prototypes and described in testing tasks should be in the natural language and use the regional preferences of users in the target market. Users should always be allowed to work in the language of their choice, entering and printing and viewing data, and seeing their local data, time, currency separators, sort orders, and so on of their region. The reality of the modern global enterprise allows us some more leeway however, and this can work in favor of more scalable UX processes too.

How to Adapt Designs, Prototypes and Test Tasks for International Audiences

  • Remove any obvious US functionality from the UI or required test tasks. For example, social security numbers, address formats, data pickers that launch US-format calendars, or popups on editable fields suggesting US date formats as examples.

Social Security Numbers are not used globally, so tailor your experience to the market

  • If localization functionality is being shown, then change the UI and tasks to reflect the reporting or other legal requirements of the country or region. For example, VAT in the EU instead of sales tax, what the various statutory requirements for employee leave and holidays are and so on. Consult with local sales consultants and localization developers to tailor the UIs.

Find out what requirements, laws and regulations are in operation for the workplace in the target market and reflect that.

  • Take care when showing personal or employment data in designs or prototypes intended the EU especially, avoiding invalid tasks that might cause privacy issues in Germany for example. Remember social media-type interactions and integrations too in this regard.
  • Adjust any functionality and testing tasks to reflect what users might do locally. For example, if searching for information using a mobile app, German users may prefer to search a German website (.DE domain) for local information, using translated keywords and so on.

Use international features to reflect the user activity of the target market.

  • Find our what are the most common formats and variables used by the organization as it works, and adjust any test tasks to reflect those. For example, rather than a list of currencies to scroll through, why not present the local users most used currencies at the top of a currency list of values.

Use the commonly used data and activities of the target market.

Other observations about taking international user experience considerations into account are detailed in the usableapps blog Cross-Cultural Factors Should Be Considered in Enterprise Software UX Design.

Decide About Translating Designs, Prototypes, and Testing Materials

  • Whether the design or prototypes needs translation depends on the user profile and the work involved, so review that information carefully. In some countries (for example, Japan, Korea, China, France, and others) using an untranslated UI for testing is not advisable, and certainly for public sector users a translated version should be used too.
  • Do not fall for the old argument that “they all speak English” when testing in European countries. Although conversational English is widespread amongst users of enterprise apps in Europe, the domain expertise required by some enterprise applications is more easily acquired and functionality understood in the native language of the user. Any public sector testing will hinge on being able to provide translated designs and test scenarios.
  • In other cases, such as testing with users in US-based multinationals, an English language UI may suffice if it uses the regional settings of the local users and the tasks involved in any testing reflect what local users do when working.
  • Depending on the market and user profile and other information you may also need to translate any test instructions, questionnaires, surveys and other materials, as well as translating any quantitative data or other observations gathered. Test sessions may also require you to use an interpreter to guide users through tasks, so pilot these sessions so the interpreter and usability engineer knows what's involved, and the right cultural approach can be taken when coaxing information out of test subjects or helping them along.
  • Use professional translation services and interpreters who preferably have domain expertise in the test area. Do not rely on Google Translate. Working with local in-country domain experts who speak the language of the user is the way to go. Leverage the language assets and expertise of the corporate translation team, or already subcontracted translation companies working on applications.
  • Create designs in formats that can be easily translated. HTML is ideal, and PhotoShop layers or Visio (VSD) files can also be translatable.
  • If you cannot translate the UI, then be prepared to explain how to users how application will be translated, and also explain how the language shown in applications can be changed further. If in the UK, for example, be prepared to deal with the issue of US spellings used instead of the UK variants by emphasizing regional support, localizations, and how the language can be changed to reflect the enterprise requirements using personalization or other extensibility tools to maximize the usability of the application.
Be ready to explain translation, personalization, and other language change mechanisms.
Personalization is particularly important in the mobile apps space (as evidenced by the Apple iOS5 personalization feature, coming).

Using Regional Settings

  • Always use local regional or common formats in user preferences. In enterprise applications, multilingual support (MLS) is critical: this functionality allows users to enter and view data in their own language and use local settings while running the UI in another language; a situation often encountered in multinational companies. Change the US defaults for dates, times, currency symbols, decimal separators, and so on to reflect what is used in the target market.

Use the regional settings of the target market. Common formats help testing efforts scale.

  • Construct test tasks that require users to enter or use data using those settings, not the US equivalents. There is nothing more infuriating to non-US user than being told to enter a date of 03/03/03.
  • If you must compromise on these regional settings, for reasons of scale for example, then choose a common format instead over the US one. For dates for example, a common format of dd-MMM-yyyy will avoid confusion internationally.
  • Even something as simple as changing the sign in name in your application to a friendly local format can make testers feel more comfortable.


Do you have any other guidance on successful internationalization of designs, prototypes or usability testing? Any observations or tips to share? Let me know, using the comments.

Friday Aug 19, 2011

Translatability Best Practices for Doc and Help

Translatability guidance aimed at user experience (UX) designers who are prototyping doc and help interactions and content. Considering these points will make your content easier to translate. Areas for attention include respecting the demands of XML structured authoring (DITA, DocBook, or other), how to share content, avoiding  translatable attributes, not contributing to the horrors of hard-coded alphabetical sorting orders, steering clear of the PRE element for tables and such like, allowing for graphics text expansion and redraw,  taking care with indexing and keywords, dealing with UPK translation issues, and so on. [Read More]
About

Oracle applications global user experience (UX): Culture, localization, internationalization, language, personalization, more. For globally-savvy UX people, so that it all fits together for Oracle's worldwide customers.

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

Ultan Ó Broin. Director, Global Applications User Experience, Oracle Corporation. On Twitter: @localization

Links

Search

Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today