Wednesday Mar 30, 2011

Apps-UX at the Aviva with OUG Ireland

I attended the Oracle User Group Ireland meet in Dublin today, invited by new OUG UK (and Ireland) chair  Debra Lilley. There was a jam-packed agenda with lots to interest the 200 attendees made up of Oracle partners, users, developers, and others.


Some Aviva attendees polishing their pitch.

I was particularly interested in the big picture-setting keyword by Oracle's Ireland country manager Paul O'Riordan (who had very positive things to say about Oracle apps UX too), and of course the sessions on applications, especially the demo of Oracle Fusion Applications that I knew Debra was going to give (Debra is a Fusion Apps UX Advocate). I was on hand to chat with attendees about how the Oracle Applications User Experience team (Apps-UX) team goes about its work. You can read more about that on the usableapps website. Suffice to say that Liam Nolan (apps development director in Ireland) did a smashing job talking about all the apps, how apps customers should deal with upgrade and maintenance issues, and introducing Oracle Fusion Applications.

Debra handled the Fusion Apps demo like a Eurovision winner - with great enthusiasm and a punchy delivery (no miming was allowed), really getting that UX message across. Afterwards, some of the attendees were interested in the UX process and what it meant for them as customers and partners. Design patterns were a hot topic, there was good insight into natural user interfaces (iPad, basically), and surprise, surprise, error messages were mentioned as something customers could use guidance on (they picked the right guy to turn up, then). Having Grant Ronald from ADF Product Management there helped complete the design to realization picture. In all, an accessible, value-add event with plenty of opportunity to network with smart people, acquire some new skills, share knowledge, and learn from the experience of others. Watch out for the next one in Ireland as it is well worth going to. How super to see the Irish flying the flag for Oracle in Europe, too. We can do it, y'know. Hashtag was #oug_ire11.

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!

Sunday Oct 31, 2010

ADF Faces Messages: Inline Versus Dialog Decisions

The Application Developer Framework Faces components (as previously mentioned) allow you to use a variety of messages types (error, warning, and so on) in different ways. For example, errors on components can be shown inline (that is, on the page - figure 1) or in a message dialog (figure 2). This is done by setting the inline property on af:messages to true.


Figure 1: ADF Faces Inline Error Message


Figure 2: ADF Faces Error Message Dialog

But how do you make the decision about whether to show the message inline? To do this you need some user experience guidance. Make the decision based on how the business or UI rule you've designed is validated and on the nature of the user task being performed. Here's a sample decision matrix for message types and scenarios (figure 3) that you might like to consider.


Figure 3: Inline versus Dialog-based Messages Decision Matrix

Of course, this is just a guideline. Natch, designing your flows so that errors aren't necessary at all is the way to go, but hey, let's live in the real world!

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.

Monday Aug 09, 2010

Unexpected Errors: Were They Ever Expected, Anyway?!

I'm sure you've seen error messages that say something like "Unexpected error occurred. Contact your system administrator." Fairly useless error messages I would say, actually, and an approach I do not promote in my team.

When, for example, is an error message ever expected? And how do you contact your system administrator (even if you know who or what that is)?


Figure 1: Why Not Just Ask Alice?

I was reminded of all this as I read the section about "Make sure your error messages cover unexpected problems" in the UX Matters article "Avoid Being Embarrassed by Your Error Messages". However, in the enterprise applicastion space, additional requirements should be met for these "unexpected errors":

  • Firstly, a unique message identifier (or number) should be attached to the message itself. This can be disclosed progressively, coming after the message or made visible by way of a 'More Details' option on the message dialog for example. These identifiers can serve different purposes: They can allow the user to search on the number and find a solution is the most common one.

    However, in many enterprise scenarios this option is usually of little use to the end user. Instead, help desk or support analysts can use the number to search for, and record, solutions in knowledge bases. Being the same identifier across translated releases, as well as the English release, means that the analyst does not need to translate the message into English to find a solution too. The analyst looks up the identifier.

  • Secondly, end users should never be told to contact their system administrator (figure 1) or to try and recreate the error or type out what they were doing (even if they could). The message handling framework should do all that automatically for the user. Oracle Apps refer to this process as incident creation (or alerting) and diagnostic logging.

    When serious messages are shown to the user an incident is automatically raised and diagnostic logs (usually) created too, alerting the help desk to the issue and collecting all the necessary background details for the help desk analyst. In these cases, a straightforward message text tells the user that their problem has been recorded for them.The technical details are not disclosed to the end user, but instead, the help desk can use the incident and diagnostic tools to deal with the cause of the problem (figure 2). End users should not be dealing with complicated tech stack details. They can't do anything with them to fix the problem.

Figure 2: Possible Error Dialog for Non-user Actionable Message

All too often discussions and guidance about error messages are disconnected from the Support framework provided in the enterprise space and the reality of applications security and roles. A posited solution based on something like "Unexpected error. We didn't think you'd ever see this message, but you have. Please contact us and give us this error code: [Error Code]" doesn't really move the user experience argument very far in the right direction of recording why an user-unrecoverable error happened automatically and doing as much work for the user as possible.

Remember that "unexpected" error messages the beginning of a customer engagement process with the help desk and possibly support analysts, so make it as easy as possible.

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.

Thursday Mar 25, 2010

What Error Messages Reveal

I love this blog entry "Usability doesn't mean UI". Especially this part:  

Ask for a list of all error messages when you do your next vendor evaluation. You will learn more about the vendor's commitment to usability and product quality than you will fathom from a slick demo.

Not so sure about the part about error messages not being "hip" or "glamorous" though.

I know... I should get out more...:)


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.


« August 2016