Ultan O'Broin (@ultan) presentation Beyond Errors: Messages for the Complete Enterprise Applications User Experience at User Assistance Europe 2011.

1. <Insert Picture Here>
Beyond Errors: Messages for the Complete
Enterprise Applications User Experience
Ultan Ó Broin, Director, Applications User Experience
Oracle Corporation
User Assistance Europe 2011 Conference

2. The following is intended to outline our general
product direction. It is intended for information
purposes only, and may not be incorporated into
any contract. It is not a commitment to deliver any
material, code, or functionality, and should not be
relied upon in making purchasing decision. The
development, release, and timing of any features or
functionality described for Oracle's products
remains at the sole discretion of Oracle.
Other screenshots shown may be trademarks of
their respective owners.

3. Agenda
• Messages – What Are They?
• Conventional Design Guidance
• Messages in Enterprise Applications
• Users and Tasks
• Message Typology
• Validation Rules
• Inline versus Dialog Box
• Warnings and Confirmations versus Undo
• Help desk and Support Considerations
• Back-end Messages
• Notifications and Personalization
• Message Text
• Conclusion
• Resources

4. Messages – What Are They?
• User assistance, part of the user experience (UX).
• Communication that
• Eases task completion, increases productivity, reduces support cost.
• Provides feedback about user actions in advance, afterwards, and
the application’s response.
• Informs users about what has happened and how to fix the problem
or obtain help.
• Not just about errors…

5. Conventional Design Guidance
• Messages are one of the highest usability issues in
enterprise applications.
• No emphasis on value or competitive advantage.
• Good for a laugh: Haiku-style derision, rogues gallery.
• Design emphasis on writing message text:
• Plain language, don’t shout or blame, provide cause
and action, and so on).
• Blame the developers.

6. Conventional Design Guidance
• Web site, generic heuristics orientation (Van Duyne et
al, Nielsen).
• Visual treatment, placement near problem, and so on.
• Messages are usually error messages.
• Never write a message as a workaround to usability
problem.
• Great, but where’s the user-centered design and
reality in all this? How and why do messages appear
anyway?
• The users, their expertise, what are they doing, their
working environment: the user experience is often
missing.

7. Guilty Examples
A file that big?
It might be very useful.
But now it is gone.
Three things are certain:
Death, taxes, and lost data.
Guess which has occurred.
(Source: Salon Magazine)

8. Designing Enterprise Applications Messages
• User profiles, tasks (the business process)
• What are the business and UI rules and how does the
technology validate rules?
• What about customization and extensibility? What’s
the message life-cycle?
• Messages are customer support too. What is the help
desk and support policy?
• What types of messages are there?
• Do you have message design patterns as well as
content guidance?

9. Message Design Pattern Example
(Copyright Oracle Corporation, 2011)

10. Message Types
Error
Alerts user to data inaccuracies when completing a field, submitting
or saving a page, navigating from the page, or when an application
failure occurs, and how to fix these issues.
Warning
Informs the user of an important decision to be made before
proceeding. May include a direct question asking for confirmation.
Information
Tells user of an application, object, or page change not caused by
the user. It does not require immediate user response.
Processing
Lets user know that an action requested or previously scheduled
is currently being performed.
Confirmation
Tells user that data was submitted or change as intended or some other
action has completed.

11. Message Types
• Get your message type right.
– Result: Consistent user experience (UX), user productivity through
learnability, easier QA, facilitation of customization and extensibility
after release.
• Be clear what is not a message (for example, a notification or UI
instruction text).
• Understand what types of message are supported by your
application’s technology and development environment.
– Determines visual treatment (icons, formatting, buttons, and so on)
automatically.
– Determines user interactions.
– You may need to design beyond what the development environment
provides out of the box.
– Understand when and where the message text will appear: in the UI
or the back end.
• See the Oracle Application Developer Framework website for
demos and examples.

12. Message Type Examples
• Warning
• Error
• Information
• Processing
• Confirmation

13. When and Why Do Messages Occur?
• Not because of the text, but because of business or
UI rules.
• A business validation rule ‘fires’ and there’s an
exception raised. Message text is required.
• An action is performed either by the user or the
application itself.
• Validation may be deep down in the code. Write text
to reflect the validation, and not other way around.

14. Validation of Rules
• Client-side validation versus server-side validation.
• Field (component) or page-level validation?
• Design message validation to reflect how the user works
• Allow users to complete in any order.
• Mark mandatory fields.
• Don’t disrupt head-down users, show messages on final action.
• Warn of unsaved changes when navigating or canceling.
• Pick inline or dialog box to suit case.
• Don’t block a task with modal dialog boxes.
• Understanding validation and types enables you write the
message accordingly. For example:
• Do you need to explicitly mention the field name in message text?
• Is the application or user acting? Passive or active voice.
• Is this a web service or integration message? What terminology?

15. Validation and Message Display Examples
• Field-level error message (navigation with other messages)
• Field-level error and warning messages listed, inline on page
• Page-level, dialog box-based error message

16. Validation and Message Display Examples
• Field level to
list level
• Navigation
between
Messages
• Resolution in
any order

17. Inline versus Dialog Box Messages
• Research:
• Inline better for task productivity
• Dialog box more noticeable
• Modal dialog box is a showstopper.
• Establish a matrix for usage based on business and
UI rules. For example:
Error Warning Information Confirmation
Serious errors or warnings Dialog Dialog - -
Navigating or completing a heads-down task. Dialog Dialog - -
Routinely data validation or actions errors and warnings. Inline Inline - -
Warnings asking a question before continuing - Dialog - -
Potentially destructive consequences of an action - Dialog - -
Application, page, or business object changes - - Inline -
Confirmations of an action with no visual indicator of change. - - - Inline
Confirmations of a process, infrequently performed, and no visual
- - - Dialog
indicator of change.
Confirmation of a navigation action between pages. - - - Dialog

18. Inline versus Dialog Box Examples
• Modal dialog box error message
• Modal dialog box processing message
• Inline page-level error message

19. Warnings and Confirmations
• Warnings of potentially irreversible, destructive
consequences.
• Explains downstream implications (affirmation) before
continuing.
• May be a modal dialog box (stops underlying task).
• Use action buttons rather than Yes, No, or OK.

20. Warnings and Confirmations
• Confirmations when no visual indicator of change.
• More rather than less, but option to personalize.
• Confirm after warning.
• Confirmations include key information, may use with
notifications.
• If action is reversible, then use confirmation and
Undo.
• Saves on advance “Are you sure?” warning messages.

21. Warnings and Confirmations Examples
• Warning message (field
level) • Warning message (page
level) with action buttons
• Confirmation message • Warning message about deletion
with visual indicator
• Confirmation message with Undo button

22. Messages as Customer Support
• Integrate error messages with your help desk and support
policies.
• Message numbers, to include or not?
• Used by help desk, support teams.
• Global, no translation needed.
• Research shows end-users don’t use them; help desks don’t want
users searching for own solutions in enterprise apps.
• Use numbers for complex business rules, back-end messages.
• Do not say “Contact your system administrator”.
• Use alerting framework to capture problem automatically for the
help desk, and then tell user what to do.
• Remember back-end messages and log files too:
• Clarity of content, technical accuracy.
• Readability online.
• Printability.

23. Messages as Customer Support Examples
• Message support number after the message text
• Error message recording application error
• Back-end message / log file

24. Messages or Notifications?
• Messaging is more immediate than notifications.
• Enterprise users may not respond immediately if not
completing a task.
• In some cases, retrieve message information later
from workflow notification or email (for example, an
expense approval confirmation).
• User preferences allow users to control when some
messages are shown.

25. Personalization and Notification Examples
• Confirmation with personalization option
• Notification for follow up later

26. Finally, Writing that Message Text
• Lots of guidance already, but some reminders…
• Plain language, sure, but…
• Write for the level of audience (end-user,
administrative, and so on)
• Use terminology that reflects the domain of user, not
the write
• Include cause and action where necessary.
• Include key information (business objects, amounts,
values)
• Standardize and re-use text, but don’t dumb down.
User assistance must be contextual.

27. Message Text
• Tokens for variables such as dates and numbers.
• If using text as token variable, then take care with
translation and internationalization.
• Understand how the message is shown. For example,
with back-end or page-level messages you refer
explicitly to UI, and so on.
• Context for translation? Generate it or write it carefully.
• Allow customers to extend and customize.
• Simple business rules, UI rule messages, and so on
should be built into the technology and never written
from scratch.

28. Message Text Examples
• Out of control message content
• Application Developer Framework validation message

29. Message Text Examples
• Audience-based components. Same message, components
shown vary by profile option
• Table definitions for components

30. Design Approach
• Collaborate on design and development.
• Understand business rules, supportability
requirements, extensibility, validation.
• Product manager, support specialist, writer,
developer.
• Flexible approach for customers, easy to modify and
change, add own content.
• Integrate with other user assistance (UI text, online
help) and don’t overlap.
• Provide means for users to help each other too
(collaboration, links).

31. Conclusion
• We looked at
• Messages, their types
• Validation, business and UI rules
• Inline versus dialog box
• Warnings and confirmations working together
• Help desk and supportability integration
• Notifications and personalization
• Writing message text
• Working collaboratively
• Effective enterprise messaging is about user experience
• Invest time in understanding:
• How people work.
• The business rules and environment.
• What the application technology supports.
• Use your messages as a window for the overall excellence of
the UX.

32. Resources
• Usable Apps: http://usableapps.oracle.com
• The User Assistance Experience:
http://blogs.oracle.com/userassistance
• Not Lost in Translation:
http://blogs.oracle.com/translation
• Van Duyne et al: The Design of Sites (2nd Ed, 2006)
• Application Developer Framework:
http://www.oracle.com/technetwork/developer-tools/adf/over