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.

Friday Apr 01, 2011

Context for All

Interesting post over on the Content Rules blog, discussing the issue of context (or lack of, really) for translators, and how it relates to granularity of content. It's great to see this issue raised and I think we need to be a lot more hardcore about examining the claims about how intractable the problem of lack of context for translation can be.

For me, the problem with this context debate is that it is decontextualized (ho, ho) from the total content lifecycle and the tools and process side of things. For one thing, has anyone considered what context an application developer or technical writer has when reusing content (whether burst DocBook objects in a CMS or DITA conrefs)? Is it any worse/better than what translation teams have? Surely, if content developers have context from their CMS (or development environment) then isn't the issue why translators aren't accessing the CMS/environment and working in there too? Why ever remove content from a database just so to translate it? What is very clear to me is that context can be easily and automatically derived from the development environment and included within a translatable file format, if you so design it. Here's a simple Oracle-related example:

xliff_context.png

Information quality helps a lot here too. A term should only have one meaning in that context. So, derived context, information quality, and repository-based operations can solve the problem. Sure, a badly written little piece of text copied and pasted into Notepad and sent around the world via e-mail is going to lead to trouble. Duh.

What translation teams should not be pushing for however, is dumbed-down text devoid of any real style or necessary references just to make translation easier. Contextual information is a critical UX. Bland, generic content is not - that stuff damages the UX in all languages. Nor should content developers have to "write in" context in the form of translation notes for translation teams. That is a waste of development time and resources. Derive the context automatically, instead.

Regardless of how this context is provided, the most frustrating part of this context debate is the lack of insight displayed by advocates about the application lifecycle. Context has been positioned by internationalization and translation teams as something exclusively required on translatability grounds. It's not. In fact, context is a critical part of any UX-effective customization or extensibility efforts.

Less than a quarter of enterprise application deployments stay 'vanilla'. The rest are customized: modified for customer needs, and with extra bits of functionality added on that need to look the same as the rest. Without context for developers and functional users, such customization/extensibility efforts can be very tough indeed in UX terms. In fact, 'translation context' columns in databases are usually repurposed description columns intended for development, implementor and customization team notes. That internationalization and translation teams never leveraged a wider argument in support of improved context doesn't surprise me.

I believe the context for all requirement is one that can be met. But it will be by UX people, and not translation teams.

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
« April 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
   
       
Today