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.

Sunday Sep 19, 2010

Observations from UA Europe 2010

As mentioned, the Applications User Experience (Apps-UX) User Assistance team made an impact at UA Europe 2010. This is one conference I will definitely be attending again. Stockholm was such a great setting too. Highlights of the conference follow:

Anne Gentle's keynote address on Social Web Strategies for Documentation was an instructive, engaging, no BS approach to the subject, along with examples we could all look up. Anne's comments about doing what was right for your business made complete sense.

User assistance must be designed and deployed according to business requirements. If social web engagement doesn't make sense for your business, then don't do it. Watch out for our forthcoming interview with Anne (update, March 2011: it's here) when we will talk about the enterprise user assistance implications of being part of the user conversation, and more.

anne_gentle.jpg

I was intrigued when Anne pointed out the need to identify your role in the conversation with the user through the social web: Reporter/Observer, Enabler/Sharer, or Collaborator/Instigator. User profiles and roles are a central part of how Apps-UX goes about its research and design work. Could we see such roles appearing officially with the list maintained by our business process engineering team? I think so, and we will design user assistance accordingly. Exciting times! Follow Anne on Twitter for updates.

Enjoyed the session by Roger Hart about content strategy at Red Gate Software. This was a forthright delivery that got straight to the point about managing your web content to reflect what users want, so adding value to the business. Basically, a strategy ensures that your content doesn't suck, or continue to suck, according to Roger. You can also follow Roger on Twitter and read his blog here.

Matthew Ellison's session on what kind of user assistance users really need made me think hard about our own design of user assistance in the enterprise space, how embedded help, warning messages, and online help can work together, and what is offered by the Application Developer Framework to easily make embedded help and messages happen for internal developers and our customers.

Most interesting of all, though, was the discussion on user assistance trends and technologies. This discussion was led by vendors, but was thrown open to all attendees at the end. For me, what was not said, rather than what was, that was most revealing. It seems to me that there are many who still couch user assistance in narrow documentation and help terms (although some clearly get it as far as the social web is concerned), and don't consider user assistance as a key part of the overall user experience. The notion expressed that Microsoft Word documents and single sourcing were a content management strategy left me cold (they aren't). Furthermore, the positioning of a content management system as an administrative back end function just removes users further from user assistance. Why not make the back end the front end? Stop talking about content management systems. Start talking about information strategies and how users search for, retrieve, and consume that information, please.

Clearly, there is some way to go in bringing user assistance into the user experience fold. I am so proud to work for a user experience group providing some thought leadership in the area.

To conclude: UA Europe is a super high-value conference. As well as an opportunity to share your views and experiences, in return you will learn much, be exposed to new ideas and processes, and also get to network with some very insightful and helpful people. I will definitely be back. Oh, (update 2011), I'm already there...

What Do Users Want Most From User Assistance? Affirmation and Confirmation

Matthew Ellison, at the UA Europe 2010 conference, presented some fascinating results from a user assistance research project undertaken with the University of Portsmouth (full details will be in the December 2010 issue of Communicator magazine).

What users wanted most (47%) was affirmation and confirmation types of user assistance. This is almost twice what they wanted of the "How do I...?" stuff. Naturally, there are always some caveats that come into play when interpreting these kinds of findings for your own business. However, based on my own observations and Applications User Experience team research, the need to inform users in advance as to consequences of their actions, how data is used, and so on, and then confirm their actions or application responses, is broadly in line with enterprise user assistance requirements too.

In Oracle Fusion Applications user assistance, we already have writing patterns that allow us to easily write DITA-based online help topics informing users in advance about consequences of decisions. However, we also provide this information contextually within the task flow using embedded help on editable fields, warning messages, and then confirming results and actions using confirmation messages. Using embedded help and messages together like this enhances productivity as the user can immediately be informed of the consequences of their actions and then see a confirmation when done, enhancing productivity.

The Application Developer Framework (ADF) Faces component demos (available for download here) show what field-level embedded help is possible (for example, see the shortDesc property on the inputText component as shown in figure 1), as well as how warning (figure 2) and confirmation (figure 3) types of messages work (see the Messages component).

shortdesc_note_inputText.png

Figure 1: Embedded Help in Note Window on Editable Field

warning.png

Figure 2: Warning Message

confirmation.png

Figure 3: Confirmation Message

Check out the demos and just see what a rich user experience is possible!

Oracle Apps-UX at UA Europe 2010

The Applications User Experience User Assistance team (well, myself, Laurie Pattison, and Erika Webb anyway!) attended the "UA Europe 2010":http://www.uaconference.eu/ conference in Stockholm.

In addition to sessions on DITA-based writing patterns  and enterprise mobile apps UA research and design, we held a lunchtime discussion on the iPad and user assistance, and took time to talk at length with author Anne Gentle and exchange views with other lots of other UA and information strategy professionals.

I am really happy with the thought leadership that Apps-UX displayed in the UA space. It's such a great group to work in! Watch out for a forthcoming interview with Anne Gentle on the usableapps website. Here's to the next conference!

Saturday Aug 14, 2010

Frequently Published Questions

We're all familiar with the concept of the Frequently Asked Question (FAQ) type of user assistance. But I have a question of my own, infrequently asked: "If it's a frequently asked question, then why?"

Frequently Asked Questions, to me, may indicate that it wasn't possible to execute a completely intuitive user experience, this time, for some categories of users. However, if a question is "frequently asked" then it also makes sense to treat it as a requirement gathering exercise; an opportunity to improve the usability of the interface as quickly as possible using the information in the FAQ itself.

FAQs are about performing tasks directly, of course, but they go beyond the straight "how-to" procedure. Some may explain the meaning of something, the consequences of a decision in advance, or the downstream consequences of a task that a user may need to know before acting, and so on.

EBS R12 Procurement FAQs

Oracle Applications Help System (EBS) Procurement FAQs 

There's a need for these sorts of orientation and affirmation/confirmation topics during task usage, but any notion that "What's this for?" "Or how do I do that?"-type FAQ topic should persist for very long in the age of agile development, or in any great numbers, makes no real sense to a user experience professional.

Let's be clear here. I am not saying that FAQs never need to be written and published. They do reflect the reality that you can't design and build everything you want all the time. Some operations may have to remain complex, some things may note be so easily learned or remembered, or there may be other reasons to write about.

But ask yourself: How often are FAQs refreshed? And what process is in place in your organization to review and eliminate existing ones? Every task-based FAQ should immediately trigger an associated enhancement request or product backlog item added to remove the need for the FAQ topic through superior design, testing, or development. Indeed, FAQ topic value should be measured through reviewing webserver logs, feedback, ratings, and user conversation, too

Plus, If you find that your customers are writing FAQs and distributing them across in the community, without reporting issues to you, then you need to do some real thinking about your user experience methodology and how you obtain feedback on user assistance or approach the notion of information quality.

Otherwise, frequently asked questions are just perpetually published answers.

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.

Thursday Jul 15, 2010

Authoring Tools on the iPad

Just a thought, but when might we see the emergence of powerful user assistance authoring tools on the iPad itself? Arbortext, Word, Framemaker and so on, and even online equivalents such as Google Docs, all revolve around a desktop paradigm of menu driven options such as File Open, Save, Print, and so on, and traditional user assistance content processes of creating a file or object, saving it, and then publishing or printing.

Will the user assistance community move to the iPad as a possible authoring platform? For on-the-spot, agile, Natural UI-based responses to issues that require content to be created and posted? My team could already run our Arbortext Editor deployment on the Mac (through remote desktop clients, natch) if we needed (though our main supported platform is for authors is Windows with the software running on a Linux server).

I wonder if iPad-based tools, which allowed the creation of NUI-integrated assistance (perhaps emulator style) as well as traditional media (searchable, XML-based, demos, and so on) could move the user assistance community forward in ways they never imagined only a few months ago?

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