Friday Jun 22, 2012

Top Fusion Apps User Experience Functional UI Patterns & Guidelines Every Apps Dev Should Know

We've announced the availability of the Oracle Fusion Applications user experience design patterns. Developers can get going on these using the Design Filter Tool (or DeFT) to select the best pattern for the context of use.

Design Filter Tool (DeFT)

Design Filter Tool selects the best pattern for your user and task.

As you drill into the patterns you will discover more guidelines from the Applications User Experience team and some from the Rich Client User Interface team too that are also leveraged in Fusion Apps. All are based on the Oracle Application Development Framework components.

To accelerate your Fusion apps development and tailoring, here's some inside insight into the really important patterns and guidelines that every apps developer needs to know about. They start at a broad Fusion Apps information architecture level and then become more granular at the page and task levels.

Information Architecture: These guidelines explain how the basic construction of an Oracle Fusion application user interface, enabling you to understand where your new components and changes fit into the overall application's information architecture. So, begin with the UI Shell and Navigation guidelines, and then move on to page-level design using the Work Areas and Dashboards guidelines.

Page Content: These patterns and guidelines cover the most common interactions that are used to complete tasks productively, starting with core interactions that are generally common across all pages, and then moving onto the more task-specific ones.

Core Across All Pages

Task Dependent

Now, armed with all this great insider design information, get developing some great-looking, highly usable apps! Let me know in the comments how things go!

Tuesday Feb 15, 2011

Great Example of Community How-To Doc

Always on the lookout for examples of community doc, and here's a great one: Chet Justice (@oraclenerd) just launched an eBook version (PDF actually) of John Piwowar's (@jpiwowar) very popular multi-part E-Business Suite Installation Guide. You can obtain it using the PayPal buttons here.

All in a good cause too. Creation of how-to information like this for functional or technical tasks, along with working examples about post-install steps, configurations and customizations, is what an applications community value-add is all about. Each community is different of course, an Adobe PhotoShop community might be more interested in templates. Great to see the needs of the community being met like this.

If you have other community how-to examples you'd like to share, then find the 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.

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!

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

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.


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