Designing Global Graphics in Enterprise Apps: Points to Consider
By ultan o'broin on Jan 19, 2011
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!)