[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: |
|
||||||||||||
| 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:
|
| 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 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. SummaryMessage banners
Alerts
Notes
Inline/bubble messages
How to deal with errors in Magnolia's UIHere'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.
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. |