[MGNLUI-2532] Evaluate error messaging in AdminCentral and ensure that they are handled properly and consistantly Created: 19/Dec/13  Updated: 09/Mar/21

Status: Open
Project: Magnolia UI
Component/s: None
Affects Version/s: 5.2.1
Fix Version/s: None

Type: Story Priority: Major
Reporter: Christopher Zimmermann Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLUI-2490 Security App: Messages send to the pu... Closed
relates to MGNLUI-2530 Error messages should not be sent to ... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Date of First Response:
Epic Link: Human readable errors

 Description   

There are several issues to investigate and address:

  • Previously when any action execution caused an exception, a message would be sent to all system users. In 5.2.1 this behaviour is changed to only send an error to the user whose action caused the exception. Perhaps depending on the type of action, additional users should be informed such as the superuser, members of the superusers group, or only the administrator of one "tenant" in a multi-tenancy arrangement.
  • Perhaps there should be configuration of which users, if any, should recieve messages when exceptions occur for any user.
  • Should there be a new method on AppInstanceController to send a message to the administrator of the current user in a multi-tenancy arrangement?
  • In response to exceptions - sometimes a message is sent, sometimes only an error notification is displayed. See Andreas' comment below for an assessment from the UX perspective and for how this should work.


 Comments   
Comment by Andreas Weder [ 20/Dec/13 ]

If you want to find out, which message to use when, we have to look at the main message types and their visual representation.

The currently available visual elements to show messages are:

Each visual element has been crafted to carry a specific type of message. Every message type has characteristics you should be familiar with, so that you're able to decide which visual element has to be chosen when.

More about three message types carried by banners, alerts and notes: http://wiki.magnolia-cms.com/x/_50OAw
More about validation messages carried by inline and bubble messages: http://wiki.magnolia-cms.com/x/Ap8OAw

For the first three types mentioned above, these can be found here: http://wiki.magnolia-cms.com/x/_50OAw . The validation messages should probably be included on that page as well, since forms are now also used in the Small app layout to specify input forms for tools and thus basically have escaped the pure input form realm to some extend.

Summary

Message banners
    • used for message type: system and app messages
    • persisted: messages are persisted to Pulse. Are received by logged-in as well as logged-out users. The only messages that are persisted.
    • context free: do not show up directly in the context I'm working on: they may show up anywhere, any time.
    • non-modal: are not blocking the user, but are somewhat intrusive (esp. error message banners).
Alerts
    • used for message type: modal messages
    • in context: show up in the context you work on (e.g. you click on an action, that causes an alert to popup)
    • modal: interrupt the user and block him from continuing until he has closed the alert
    • request input: require the user to confirm the message or give input
Notes
    • used for message type: notification
    • in context: show up in the context you work on
    • non modal: do NOT interrupt the user (ok, the current impl does, but that was not the intent)
    • temporary: they disappear by themselves. It shouldn't matter, if they go unnoticed. When returning from the coffee machine, you should still be able to determine, what has happened in the mean time.
Inline/bubble messages
    • used for validation messages in forms
    • in context: show up in the context you work on
    • in a form: are only used inside forms, embedded forms or form-like input masks such as those used by tools

How to deal with errors in Magnolia's UI

Here's my first attempt at a quick check list for how to deal with errors. I plan to have a closer look at this on a card in the human interface guidelines.

  • Try to avoid actual errors by validating input and preconditions early on... and often:
    • It's not ok to run a task to just see how it fails miserably, just because some preconditions werent' met.
    • Try to determine if all preconditions for a task are met using validators. If they are not met, use an inline message to signal the problem ("you don't have the necessary write access permissions on this directory")
    • Validate actual input directly in the form/UI. Use an inline message to show problems (note that you may also show warnings).
  • When you encounter an error:
    • show it in an alert, if it requires the user to notice it and when the task has to abort or needs input before it can continue
    • in general, do never use a notification for signalling errors - they go unnoticed too easily. Instead, I'd like to put more weight on validation before kicking off an action.
  • Only use a notification to confirm that an action was aborted. E.g. the user uploads an archive, decided to cancel mid-field -> you show a (red) error notification to confirm that the upload was aborted. Note that the user can also determine that the upload was cancelled by looking at the UI (no progress bar anymore, but also no uploaded files)
  • For critical errors (exceptions), use a banner to make sure the message gets logged and could potentially be forwarded or analyzed further. Typically, it's enough to notice the logged-in user only.
  • For severe errors (exceptions that lead to the app being in a bad state thereafter), also use a banner, but notify administrators as well
  • For security breaches or similar, again use an error banner and notify administrators.

All of the above requires error messages must be fine-grained so they can be properly caught/dealt with and shown. If all you do is throw a single type of exception to signal errors in code, you're probably on the wrong track. Note that exceptions are also pretty bad performance-wise: raising them needs a lot of processing power and memory.

Generated at Mon Feb 12 08:57:36 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.