What makes for a great, compelling and modern user experience? Context. Context of use, context of device, context of task, all revolving around a source of truth in the cloud: that customer, that employee, that sale, that general ledger. And what makes for a great translation (or localization as the rest of the industry would say)? Context.
Here's a presentation I delivered at Localization World, London 2013 that shows how the two can work together. For me, context is just as useful for implementers and developers as it is for the translation team. And certainly providing the context for a great string in the UI, in any language, is what makes for a great experience.
Yes, voice-based user experience has been around for a while. HCI freshmen grappling with Molich and Nielsen's seminal 1990 CHI paper on usability heuristics for the past two decades would have come across such user interfaces - twice. Even on mobile phones voice assistance is not new. I've used voice-based Google search on my iPhone and Google Translate Conversation Mode on my Nexus S for a long while now, for example. But now the inclusion of Siri as a native feature on the iPhone 4S has really caught the attention of the consumer market and UX professionals alike.
What are the enterprise applications user experience (UX) implications of Siri?
What are the global UX aspects to the Siri potential?
As a UX professional I can see Siri use cases for mobile workers, sure, for simple input and creation tasks, but also for finding and manipulating more complex business transactions by taking direct action on data, contacts, locations, analytics, you name it, from one small device. Richard Bingham has some great points about Siri's potential in the enterprise customer service space.
Siri offers a logical means of interacting with devices that are essentially phones while on the move-your voice-and takes the natural user interface experience currently dominated by gestures to a new level. Obviously personalization and alternative interaction options will still always be needed as not everyone will want to use voice-based assistance all the time. Fine for telling Siri to approve an purchase requisition in your worklist or to map a route to the next service request within a 5 mile radius while you're driving (using a headset mind), but nobody is going to intone, Stephen Hawking-fashion, into their iPhone "Tell me who won't make quota in my sales territory this quarter" while waiting in line in Starbucks. For enterprise use, a more scalable service will also be required. An ability for Siri to handle domain-specific terms and jargon that a now comprehensive range of enterprise applications user profiles use in their conversations is a requirement too. With the mass uptake of iPhones and the fact that Siri learns from input means that shouldn't be a huge problem.
As far as I can tell in terms of international language support, Siri supports English sure, especially well if you like to speak like a real android, but also French and German. Additional languages will be needed to penetrate lucrative Asian, Japanese and South American markets. It will need to handle the more, shall we say, nuanced accents of non-native English speakers too. All this is very doable. Siri uses Nuance Communications technology acquired from the infamous Lernout and Hauspie, so global capability is in the DNA. As for usage in the field worldwide, will mobile workers in every culture take to Siri the same way, or at all? Looks like a fine ethnographic study on mobile voice assistance use in the making.
Can we expect Google and Android to react? You bet. With all that mobile Google Translate and search expertise expect something spectacular before the iPhone 5 appears. Of course, Siri is currently beta anyway, so by then, Apple will have moved it along significantly too.
What are the best practices for
localization (in the enterprise applications translation sense of the
word) operating within the agile software development framework,
using scrum for example? I posted a similar question on Quora, and haven't
exactly been overwhelmed by the response. Not
much change there, then.
The best reference I can find on the
interwebs is Tex Texin's (@textexin) document Agile
LocalizationPractices. Recommendations (October
2010). I exchanged some email with Tex about this piece before it
was published, so I should disclose I have more than a passing
interest in it. I would agree with Tex that the
localization industry appears to be reacting to the agile framework
adoption rather than help determining it. The evidence from the interwebs
is that LSPs have a stock response in the affirmative, “Yes we do
agile”, while being very low on 'how-to' specifics or showing any real thought leadership
Here are my own observations on the
general seeming lack of 'hard' information.
One thing is very clear to me: If
you development processes and tools aren't up to the job for
agile-based operations, you will find out pretty quickly. Same for
translation tools and processes. Whither the role of the crowd
and disruptive innovation in agile localization.
Internationalization (I18n) is a sine qua non for any agile-based
localization, not just the basics of character set handling, code
conversion, multilingual tables in databases, and country, language,
or regional-neutral code that can handle variabilized settings for
currencies, dates, times, sort orders and the rest, but
translatability. Make sure your product uses technology that is
internationalized, but pay attention too to areas of composite
messaging, string externalization, the building in of context,
and of unique and persistent Ids on strings and content or other
devices to aid reuse.
Agile has key advantages in the
areas of shortening innovation cycles, exposing technical and
project risk early, and shortening time-to-market for competitive
content. Getting real, working content out there to a global
audience in multiple languages, early, means a better global UX too.
The idea behind the framework is that all functions are performed
together within sprints, rather than preceding or bolting on
particular functions to the entire process – usually the latter,
waterfall style. Parts of the traditional localization (and UX)
process are immediately pressured by this agility.
How is terminology
developed (for source and target)? Using locked-down, frozen
terms in advance of development is hardly agile, yet it's common.
Terminology takes time to research and develop in a source language,
and getting the language equivalents agreed and onto some kind of
usable system isn't an overnight task either. Terminology is also
going to change during sprints, in response to customer feedback,
like it or not.
Possible solutions here are to start the agile
process with the best terminology available, using possibly
crowdsourced validation, and revise terminology as customer feedback
comes in, in context from real user. Or allow users to personalize
their own user experience. Why try to anticipate the ever-changing
mindset of say, teen gamers in Korea when you can accommodate their
opinions another way. An term submission and approval workflow and
ability to reapply terms to code rather than a spreadsheet of
opinion is the way to go here. A terminology-only sprint isn't
Testing localized versions should
be done in parallel. A build environment that can produce localized
product or site versions automatically at regular intervals and
publish them to customers for evaluation can be used. In the
enterprise applications space, where complexity of functionality,
and the need to integrate with other products, databases, and
technology stacks, agile translation testing requires automation,
coordination, and the setting of clear expectations as to what is in
each build is a requirement, and isn't easy. However, a testing-only
sprint ins't agile. That's the waterfall we all know and love so
Communications across all
stakeholders in the localization process also needs to be
considered. How is that done between development, internal client
localization management, outsourced LSP project management,
in-country translators, localization QA and linguistic experts
working globally, across time zones? Does the daily stand up meeting
scale in cyberspace? Video-conferencing? Plasma screens of daily
objectives? Web-based reports? Scrum of scrums? Best of luck.
Some content is probably better
suited to the agile localization process than others, and the range
is broad: social media, web sites, mobile apps, games, anything
where UX and language decisions are heavily dependent on user opinion or more complex UX-critical
deliverables that don't require a ton of technical integration or
the provision of dedicated build environments for each language
version for sure. Content where terminology and style isn't mission
critical works well with repositories full of stodgy content, but
that's hardly competitive.
In some of these areas, the
traditional notions of language quality are challenged anyway, and
the decisions of the users are the deal-breakers on what works in
the market, not professional linguists. Such an approach only works
in the enterprise applications space if its moderated carefully.
Some middle ground, based on iterative process of getting good
enough fast enough would work, but not if you're implementation
cycle takes months, and you're a public sector organization behind a
firewalls with very strict demands on what can and cannot be said.
Tough calls for product owners.
Consider, of course, localizing
user assistance (PDF, online help, multimedia). Very easy to say
topic-based content is the solution, but how does that really
help? What of the information quality? How is that content rendered?
How much translatability
has been considered? And what of the budget for this? If users don't
want documentation, fine, but how do you know? It may be required to
help users configure their application and actually use it. And in
some markets, translated doc may be a legal requirement. How fast
can you write doc or create videos or demos, and localize them to go
with the software?
As for acceptance criteria and
review meetings, well, how is feedback from global users and
localization teams accommodated? What is the process for improving
translatability and translation tools? How are development processes
influences to improve the process next time around? How is the
feedback from international customers made to support, to
development, to product development? What about real-time feedback
from users? Bug databases online? Focus groups? Private Twitter
stream or Blackberry IMs with real users? Does your organization
have any track record of doing any of this really well, anyway? If
not, why would agile be any different?
Finally, why assume the source
code and content is in English? How would an agile framework work
for a Japanese game localized into English (or Korean for example).
Do tools and processes work for those scenarios?
I don't know of any organization
providing meaningful agile or scrum training aimed at integrating a
full localization process into a product life-cycle. If you know of
any, let me know using the comments. Other observations on agile and
scrum are welcome too. Lots of questions, not too many answers. “Yes,
we can” is a fine declaration, but let's hear some “Here's
how we can do it...” statements too!
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)!
Ultan Ó Broin. Director, Global Applications User Experience, Oracle Corporation. On Twitter: @localization