Wednesday Nov 09, 2011

Czeching out DITA Europe 2011

Attended the DITA Europe 2011 Conference in Prague. Presented with Erika Webb (@erikanollwebb) the research into using comics to explain DITA concepts. Delivery went down very well, positive vibes, lots of interaction in the Q&A session, and a few souls now up for trying comics for themselves as a result. Score.

DITA Europe 2011 at the Marriott

Clearly, from what we heard at the conference there is a need for getting across to writers the fundamentals of DITA and structured authoring, so comics are worth a look if you find yourself with that need.

Loved Marie-Louise Flacke's (@flacke) session called iconmania: the use of icons in documentation when they are neither needed nor wanted--just because you can--and the dismal result for the user and DITA adoption. Future stress testing is clearly required by the IMF (Icon Monitoring Foundation) and the time is now right for a French woman to bring some badly needed sanity to the global icon commodity market, methinks.

Slide from iconmania presentation

Delighted to also find a copy of Oracle's Marta Rauch's (@martarauch) article on mobile user assistance in circulation at the conference by way of the Center for Information Design and Management's Best Practices Newsletter.

CIDM newsletter

It was encouraging to hear about a widening use of personas and task analysis in information design and about the need for usability testing of DITA artifacts and outputs. Still not enough user-centered design methodology being demonstrated IMO, but it is moving in the right direction. The now established practices of community content engagement and the buzzword du jour "gamification"  surfaced in ways that, to me, seem orthogonal to DITA. Uptake and success of a community content strategy with or without the use of game mechanics doesn't depend on DITA. As we heard at the conference, a “build it and they will come attitude” isn’t sufficient.

SAP appears to have DITA nailed as a corporate mandate (Oracle does not use DITA on this basis) and clearly has a very well-defined and managed way of going about evaluation and implementations that reminded me of the SAP diligence when adopting information quality tools (DFKI/Acrolinx).

Translation, generally, within the DITA context, continues to be spoken about in somewhat janitorial terms of a declining cost (y-axis) over time (x-axis) imperative. Whether the source or target information adds any user value in the first place--discussed within the context of the total cost of a full content life cycle--might be a more constructive approach.

Generally, I remain unconvinced about DITA saving greater translation cost than any other proper content strategy management. To reduce word counts, ergo the most visible variable in cost of translation, what you do need a change management strategy that includes migration, talent management, training, enforcement, and reporting, but above all user-centred design principles and a change in writing behavior.

DITA translatability best practices that I come across are conceptually no different from those for dealing with linguistic, rendering or processing issues in other translated formats (see my own). DITA best practices for machine translation (statistical or rule-based) remain elusive, however.

Sessions on multilingual asset management made the case well for dealing with all the large number of topics, files, objects associated with DITA-based information development, and the promise of visualization of those assets seemed a brilliant feature idea (reminded me of eye tracking scan paths) for any CMS rather than the unwieldy object trees and hierarchies we see now.

Slide from macroscopic vizualization presentaton showing DITA objects and usage

Great to be back in Prague after all these years. Once I finally got through the shambolic passport control at the airport (nobody in the EU should accept such bureaucratic buffoonery in 2011) and got to the city, I found Prague's character hadn't changed too much since I had been there in the 1990s: wonderful sights, sounds and smells, and taxi drivers each worth avoiding by a 10km radius.

Dancing House, Praha

There is a frustrating lack of multilingual signage at key points in the city. However there are some welcome new locations that require no translation at all, so I was happy.

Starbucks Praha

I easily navigated about the city on shank’s mare and the superb public transport, relying on Google Maps on the iPhone again. Never got to try Czech option on Android Google Translate Conversation Mode. Next time. Maybe at passport control.

Google Translation Conversion Mode on Google Nexus S

In all, a well-attended conference (120+, I’d say), excellent organization, varied subjects and expertise levels, and a superb location that’s easy to get to if you’re in EMEA. Certainly, plenty to think about after the conference, which is always a win.

Thursday Oct 06, 2011

PayPal Error Message 3005: Where User Experience and Translatability Collide…

… and neither comes off very well. I received this huge error message as I was updating my credit card details in PayPal. I was working in the English language, yet this multilingual monster came my way.

PayPal Message 3005

Generally, these multilingual messages cause translatability issues. Most translatable files conform to a bilingual source-target paradigm, and not a multilingual one. The single language target enables better use of language assets and flexibility with process. Of course, the arrival of CMS and GMS-based translation solves a lot the coordination problems of keeping multiple languages translation in sync. It is also possible this message was served up from a server way rather than being actually multiple translations in a single container on the file system (I didn’t view the page source). Regardless, why bother? The users working language is known.

As for those message numbers (Message 3005), are users expected to look them up and act? Generally in the enterprise applications space these numbers are only useful to help desk or support personnel or specialized functional administrators with the right security permissions to actually do something with the application in response to looking up what that number means in a knowledge base. In this case, looking up the number leads to frustration too.

Dealing with these generic application failure issues has long been a user experience issue. If would have been better to throw a shorter specific message in my working language was shown, one with a more precise title, a cause text that reflected what I was doing, and a precise action text to perform to fix the issue. An assurance that my money and other personal details were safe too should have been provided. Making that message number and some diagnostics available on demand only, and capturing any details in the background so that a security specialist or other help desk person could check that none of my data was compromised would have been preferable. At least I was not told to contact my system administrator, so I am thankful for that!

Wednesday Sep 07, 2011

What's in a Name: Global Considerations for Apps

Enjoyed this article about the assumptions made by programmers (and therefore developed applications) about names:

Falsehoods Programmers Believe About Names

"My system will never have to deal with names from China.
Or Japan.
Or Korea.
Or Ireland, the United Kingdom, the United States, Spain, Mexico, Brazil, Peru, Russia, Sweden, Botswana, South Africa, Trinidad, Haiti, France, or the Klingon Empire, all of which have 'weird' naming schemes in common use."

Head-wrecking stuff. Actually, it's a little unfair to blame it all on programmers, they aren't the only ones to fall into this trap, and if they have not been educated in the ways of internationalization, there's little point in blaming them. However, there are serious UX implications of these kinds of assumptions. You can read more about this impact on users in the usableapps entry Cross-Cultural Factors Should Be Considered in Enterprise Software UX Design.

"Names may require prefixes to delineate male or female employees, but sometimes there is no place to put these prefixes in the form fields. And some recent immigrants to Europe do not use last names (for example, those from Myanmar, Afghanistan, and Pakistan)."

Oracle Fusion Applications offers superb support for global names and how the user wants to see them. That's another post.

Bottom line:

  • Don't allow developers to design your apps, leave that to user experience professionals.
  • Internationalize code so that it is neutral of any one name format and can be localized for regional requirements.
  • Investigate your target market and what regional conventions means for the UX and design accordingly.
For more great information on the global challenges of handling names, and how you might deal with them on the UI and database side, see the W3C's Internationalization article Personal Names Around the World.

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