Monday Sep 19, 2011

Squirting is a Software Experience? Mind Your Language, Please

The language used in an application's user interface (UI) is a critical aspect of the user experience (UX), bit one often overlook. Des Traynor (@destraynor) brought this importance artfully to life at Refresh Dublin in his presentation on the Language of Interfaces. Well worth checking out, Des emphasized how language choice determines user action and engagement, with the simple choice of text for a button label or placeholder for status update making all the difference.

In Oracle Fusion Applications, for example, there's a big difference between the button labels Save, Submit, or Done, and the action that they imply to take on a page. Save implies an intermediate state during data object or process creation that the user will return to later before the task can be finalized. Submit is a final action, committing an object to the database or handing off a process, thus ending the task. Done is generally used to conclude the user review of a read-only page, closing it.

Save and Submit buttons together on a page

Google Wave's choice of Done however (as pointed out by Des) didn't help much with the puzzling concept of what anyone was expected to do with a wave to begin with. Language alone isn't going to save a rubbish UX.

Google Wave UI Done button

Des used some great examples from social media to as examples. Compare the language and action implied of the Facebook friend with the LinkedIn contact or the contact categorizations of Google+'s circles. Determining the action should shift from a third-person to first person paradigm led Facebook to change its status update text to What's on your mind? Twitter switched from What are you doing? to What's happening?

US English Twitter and Facebook status placeholder text

Not every natural language follows the English direction however. What's up with that? And, what about the challenges offered by crowdsourced language (as in the Dutch version of Twitter)? Facebook's community translation feature, as I pointed out before, is as much a user engagement strategy as a way of obtaining translated UIs (but not help) very quickly for the local market.

French and Dutch Twitter status placeholder text

French and German Facebook Status Placeholder Text

This choice of evolving or action-intended words can be a challenge for controlling the action globally. My old friend Frank Dietz in Multilingual magazine tells of the challenge of finding German translations for gaming concepts (buff, debuff, kiting, toon hop, and so on) for example, having to rely on transcreation, Denglisch, or the English term itself.

What the presentation didn't cover was how the language in the UI drives the creation of language around the intended action within the user community too. Unfriend, for example, appeared nowhere in the Facebook UI, but is a well-established word now. ReTweeting (or RTing) was a term and concept that came from the Twitter community, before it was codified. Personalization features that allow users to control the language or add their own are critical UX features too, particularly in the mobile space.

Apple iOS5 shortcut personalization feature

As for the choice of squirting to convey the sharing of music in Microsoft Zune (see Des's presentation), well, nobody over the age of five should be squirting anything at anybody, should they? What were they thinking? And yet,they're back with internet charms...

Find those comments...

Wednesday Jan 19, 2011

Language and Usability: It Doesn't Have To Be That Way. And It Shouldn't

I enjoyed this very telling comic strip about how some usability professionals might regard language when it comes to designing the user experience:

" for the text... just copy something from Wikipedia and polish it up a bit."

However, it's unfunny because very often it's true. Still don't get it? Read the comments of some of our sales folks, partners, and customers (names have been removed to protect the innocent):

  • "When the language is IT-speak and not normal speak, it is part of the usability problem." 
  • "When users know what things mean, they're halfway there. When options are 'simple' English, it's obvious where to look and what to do... the language for users must be clear and helpful." 
  • "The quality of language in the user interface (UI) is a deal breaker."
  • "The competitive playing field has changed since the old days. Customers even do their own usability testing and include language heuristics now. It's a competitive issue."

So, in Oracle Fusion Applications we've spent a great deal of time getting our language (terminology, style and grammar) right for our users. Developers don't create the language you see in the UI or user assistance. There is a comprehensive terminology creation and management process and a multi-stakeholder review process for all UI strings, messages, and help content. Language is a user experience issue and that's why we continually invest in our information quality efforts. We have to. It's a strategic competitive issue for sales and as a productivity issue for users when they work. Watch out for more information about information quality in Oracle Fusion Applications on this blog in 2011.

Wednesday Dec 22, 2010

Chrome Web Browser Messages: Some Observations

I'm always on the lookout for how different apps handle errors and what kind of error messages they show (I probably need to get out more). I use this 'research' to reflect on our own application error message patterns and guidelines and how we might make things better for users in future. Users are influenced by all sorts of things, but their everyday experiences of technology, and especially what they encounter on the internet in their own, increasingly sets their expectations for enterprise applications.

I recently came across a couple of examples from Google's Chrome web browser that got me thinking. In the first case, we have a Chrome error message about not being able to find a web page. I like how simple, straightforward messaging language is used along with the optional ability to explore things a bit further--for those users who want to.


The 'more information' option shows the error encountered by the browser (or 'original' error) itself in technical terms, along with an error number. Contrasting the two messages about essentially the same problem reveals what's useful to users and what's not. Everyone can use the first message, but the technical version of the message can be explicitly disclosed by the more advanced user to pursue the problem further. More technical users might search for a resolution, using that "Error 324" number, but I imagine most users who see the message will simply try again later or recheck their URL. Seems reasonable that such an approach be adopted in the enterprise space too, right?

Maybe. Generally, end users don't go searching for solutions based on those error numbers, and help desk folks generally prefer they don't do so. That's because of the more critical nature of enterprise data or the fact that end users may not have the necessary privileges to make any fixes anyway. What might be more useful here instead is a link to a trusted source of additional help provided by the help desk or reputable community. This takes me on to the second case, this time more closely related to the language used in messaging situations.


Here, I first noticed by the using of the (s) approach to convey the possibility of there being one or more pages at the heart of the problem. This approach is a no-no in Oracle style terms (the plural would be used) and it can create translation issues (although it is not a show-stopper). I think Google could have gone with the plural too. However, of more interest is the use of the verb "kill", used both in the message text and the action button label.

For many writers, words like "kill" and "abort" are to be avoided as they can give offense, or so I'm told. I am not so sure about that judgment, as really the use of these words cannot be separated from the context. Certainly, for more technical users, such words are fine and have been in use for years, so I see no reason to avoid using them if the audience has already accepted them. Most end users too, I think would find the idea of "kill" usable and may even use the term in every day speech.

Others might disagree--Apple uses a concept of Force Quit, for example. Ultimately, the only way to really know how to proceed is to research these matter by asking users of differing roles and expertise to perform some tasks, encounter messaging experiences like the two here, record the findings, analyze them and then make recommendations for our designs. Something to do in 2011!

Wednesday Aug 18, 2010

Changing Language

Interesting post from the BBC about how the internet influences our language, citing examples from English, Ukranian, and more. How does this influence users of enterprise applications? What are their expectations about terminology and phrasing?

Only one way to find out. Ask them!

Saturday Aug 14, 2010

Language Should Never be 'Plain'

I see a lot of UX professional debate on the subject of plain language. Many of these arguments are decontextualized. They often import personal frustrations from filling out government forms in the US or EU, anecdotal evidence about technical error messages, and so on. This is not very helpful for making a case about what language user assistance should use for the enterprise applications user experience.

Sure, we must communicate ideas clearly and succinctly, but we must also do so using the terminology of the target audience's roles,expertise, and how they actually work. Generalizations about plain language certainly seem very reasonable when we discount such variables, aren't they? Often we see recommendations made for one design context that simply don't apply in the other.

The most notorious one in the user assistance area is the conflation that all online users read publicly available web content the same way that they would read content in the enterprise space (for example the "golden triangle" or "F-shape" argument). These findings do not hold true in the enterprise applications world.

Same for language on the web. Instead of talking about some globally applicable 'plain language' being required by all users, the discussion needs to move in the direction of information quality, and away from the dominance of internal linguists, and towards the conversations in the user community.

Information we deliver in user assistance components should reflect the needs of the user and how they work. We must use terminology that our users recognize and use consistently when interacting with the UI, searching, reading online, and most importantly, when they seek help or help each other. Getting your terminology right is central to information quality.

Engaging the user community and their conversations is key to this. On one level, it's easy. Why call "breadcrumbs" something else if the term is widely accepted in general use? Or why say "Enter a valid password" when you can say "Enter the correct password"? And, then, of course, we have some language used without thought of use at all (like "OK" in dialogs instead of more meaningful button options).

But, in the enterprise space with such a broad range of domain expertise and many possible roles, involving specialized vertical, functional or technical expertise, additional layers of complexity are added to our choice of words. User experience is about knowing who our users are, so use that research.Terminology, and therefore language, can hardly be 'plain'. This is an area that interests me greatly.

So, stay tuned to this blog and the usableapps website  for news about UX developments concerning language and user conversations.

Friday May 28, 2010

Oracle Usability Advisory Board, Europe

Earlier this month, I attended the first Oracle Usability Advisory Board meeting in Europe (held on Oracle's big campus in Thames Valley Park (TVP, Reading, in the UK). My main initial interest here, initially of course, was to listen to customer and partner experiences and requirements in the area of "applications user experience": (UX) - focusing in on the user assistance side of that, natch.

However, given my background in the language, translation and internationalization world, I was also keen to watch out for issues in those areas that impact on the UX. Information quality is fundamentally a user experience issue, after all - regardless of which natural language it ends up in. I met some great people at TVP and took away some powerful UX thoughts about where might go with the area of language in the UI, localizations, and other cultural issues. One area of special interest to me is language as part of the user experience.

By "language" I mean terminology and style of wording you see in user interfaces, error messages and help. Is this language reflective of how people really work and are used to? What is its relationship to competitiveness and productivity? What about customization and extensibility? An area rich in research potential for UX, I think. And why do many automatically assume everyone in Europe's happy with English (especially U.S. English) content? For some, it's a very serious issue! And why shouldn't it be? In terms of the web and selling, the importance of language is well explained by the Common Sense Advisory article "Can't Read, Won't Buy".

Debra Lilley of Fujitsu (an Oracle partner), who also attended, has some good coverage of the event. On to the next one! In the meantime, I will be following up with the attendees to explore some ideas further.


Oracle Apps Cloud UX assistance. UX and development outreach of all sorts to the apps dev community, helping them to design and deliver usable apps using PaaS4SaaS.


Ultan Ó Broin. Senior Director, Oracle Applications User Experience, Oracle EMEA. Twitter: @ultan

See my other Oracle blog on product globalization too: Not Lost in Translation

Interests: User experience (UX), PaaS, SaaS, design patterns, tailoring, Cloud, dev productivity, language quality, mobile apps, Oracle FMW, and a lot more.


« July 2016