Sunday May 13, 2012

Mobile Geolocation Check-in Apps Text Style Notes

My research notes on the language style used by mobile geolocation-based check-in 'n' challenge apps, foursquare, Google Latitude, SCVNGR, and Yelp are available for download. Based on my field usage of the apps, this technical communications research brain dump is for you to make of it what you will and go in peace.

foursquare, Yelp, SCVNGR

Left to right: foursquare, Yelp, and SCVNGR screens

It’s apparent from this little distraction that, with the notable exception of the active voice and references to “you”, most of the remaining styles would fail the checks in operation by enterprise applications QA teams.

For such an informal, casual, or conversational style to ‘work’ for apps users, the context of use (who, what, where, when, with) is critical. This style of language, with a little bit of common sense applied, is acceptable to a range of user profiles in the enterprise world performing mobile tasks in CRM, for example. Enterprise apps users now navigate their world of work with a user experience (UX) influenced by the demands of BYOD, Facebook-driven globalization, Globish, and the consumerization of information technology.

What is listed in my document require some nuance to be acceptable to a wider range of users, as personal appeal, energy and edge leverages users’ motivations and goals while delighting them during use. Some of the more outré messages and cultural references would need changing, sure, but there is nothing in the source that could not be customized or localized. Consider it another form of affective or "emotional" user assistance.

I had the opportunity to write some such text for a check-in and challenge app recently. It’s not easy. What did I learn?


  • Research language style and grammar in context (use the mobile apps yourself in a sort of self-reflecting ethnography similar to the "going native" work done by the Oracle Applications Mobile UX team). My research was done in the Starbucks on the streets and airport terminals of Atlanta, Dublin, Geneva, and London, using Google Nexus S and iPhone devices with multiple user accounts.
  • Design with real text and not lorem ipsum text placeholders. To begin, write something, anything, that reflects the required UX, and revise it after some review and testing. Read Getting Real about this (a thoroughly recommend book all over for web apps UX).
  • When writing text you need to have context, such as a description of the check-in, when it happens, and what happens around it (do you need to congratulate on this achievement and extort to the next one too?, for example), a visual of the check-in badge or challenge details, and so on. Access to design materials, wireframes, prototypes, or beta versions makes writing a lot easier and innovation cycles shorter.
  • Throw your existing style guide out the window. Write a user conversation instead.

Comments welcome.

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:

"...as 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.

Thursday Sep 30, 2010

No More Fart Apps. Would We Ever?

I loved Lucy Kellaway's (she of the Financial Times) article "Words to describe the glory of Apple" comparing the language style used by Apple and Microsoft and wondering if language style impacts the bottom line. If you don't want to register for the article, then the podcast version is here.

iFart Screen

Ms Kellaway tells us that Apple's language makes for content that is "fun to read", "elegant", and "makes you laugh". It has a tone that is "direct', 'comic", and "elegantly threatening". She contrasts this with the Microsoft language used for the new version of Internet Explorer, "architected to run HTML5, the beta enables developers to utililize standardized markup language across multiple browsers" and the rest. This is "standard stuff" from Microsoft, and Luce is "irritated", "bored", "alienated", and "restless" with it.

Actually, I think the article is unfair to Microsoft, who do care about language and the example used is not representative of language used in other Microsoft products - games, for example. Plus, the audience for their words is different to Apple's; basically it's a marketing pitch to Microsoft's partners, encouraging uptake of a beta release.

The Apple language that Ms Kellaway admires is taken from the App Store Review Guidelines (full PDF version); a set of guidelines more likely to be read by geek and hobbyist developers working from home than the corporate equivalents. Such language is not used in other Apple products themselves. In fact, language quality is not an acceptance criterion for App Store submissions at all. That of course, is telling in itself. Why not let the market, the users, decide on the language? In line with this, the Human Interface Guidelines from Apple for the iPhone has a common sense approach to language style. For example:

In all your text-based communication with users, be sure to use user-centric terminology; in particular, avoid technical jargon in the user interface. Use what you know about your users to determine whether the words and phrases you plan to use are appropriate.

For example, the Wi-Fi Networks preferences screen uses clear, nontechnical language to describe how the device connects to networks. Very reasonable from a user experience perspective. But, then Lucy says: "You might think there was a clear commercial advantage to be had in writing clearly and stylishly. But you would be wrong."

Not quite. There is a relationship, though it may not be all that visible to key decision-makers. That's because the commercial advantage does not come from writing clearly or stylishly per se, but its application. It comes from writing content that users actually want, in a way that they can understand, using terms and language that suits them; and that facilitates easy search and retrieval. The result is a quicker transfer and comprehension of information leading to better productivity for users and less training and support costs. And that's a competitive advantage.

In the enterprise applications space the opportunities for a product language tone that is "fun", "comic", or "elegantly threatening" doesn't exist in the same way it does for the iPhone app development community (and let's face it - for all the BS about the iPhone - most apps are little better than free low-tech toys designed by rank amateurs).

But that's not the point. The point is the language should suit the audience for the information. We need to spend less time worrying about our internal language style and all its nuances and rules and concentrate more on how users - our customers - themselves want it to be, and actually use it. Bringing terminology in line with user expectations and concentrating on a few basic writing principles grounded in research on information search, retrieval, consumption, and problem-solving would yield far better bottom line results than fretting about a rigorous adherence to every single aspect of a style guide for no other reason than it's there.

About

Oracle applications user experience (UX) assistance. UX and development outreach of all sorts to the apps community, helping to design and deliver usable apps.

Profile

Ultan Ó Broin. Director, Global Applications User Experience, Oracle Corporation. On Twitter: @ultan

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

Interests: User experience (UX), user centered design, design patterns, tailoring, BYOD, dev relations, language quality, mobile apps, Oracle FMW and ADF, and a lot more.

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