Beyond Errors: Messages for the Complete Enterprise Applications User Experience
1 like697 views
The document discusses the importance of effective messaging in enterprise applications to enhance user experience and productivity. It outlines various types of messages (error, warning, information, processing, confirmation), design guidelines, and considerations for validation and support integration. Additionally, it emphasizes the need for clear communication to users and collaborative design approaches for improved usability.
Beyond Errors: Messages for the Complete Enterprise Applications User Experience
- 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