Open dontpanicgr opened 6 years ago
I'm going to add this https://github.com/transifex/txds/issues/4#issuecomment-363752298 which is a comment that might be related and try to give a summary on a discussion we had today with @dontpanicgr.
And some questions on this:
PS. Though I love when we create something new that is more visually appealing, imho consistency > visual beauty, so I'd be more happy with a less attractive but consistent messaging.
Agree with all things you said. Wii try to add only new remarks!
Update if you find an article or reference worth mentioning.
Error prevention 10 Usability Heuristics for User Interface Design
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
Would it also make sense to monitor certain components for unexpected errors? So, a component could have a fallback error condition (for when something unexpected happens) which would log some information so that we can see if we missed something that should be handled by the component in a better way or if something is just breaking and needs to be fixed. It could even be a message to the user, "if this error persists please contact us with this reference number."
Found another article with good/bad examples. https://uxplanet.org/how-to-write-good-error-messages-858e4551cd4?ref=uxdesignweekly
How do we handle errors in the product? Currently, we have: 2 custom components (resources, schedulers [new]) 3 defined components in styleguide (system messages, notifications, status) & coming soon solutions like (toast, flag messages...) https://github.com/transifex/txds/issues/7
I started with a question though we all know that we handle errors in a complex inconvenient way for users which doesn't comply with simplicity and modularity principles of our design system.
This uncertainty of which element to use has an effect on development and design and for many times we saw ourselves scratching our heads and iterating again and again on existing elements. Most of us experienced repeated conversations of what to choose in each use case and re-inventing the wheel -- a process that is not productive.
I suggest we should explore and discuss again the structure and semantics of error messages component which by completion will save us hours! in development and decision making.
@mikegianno @codegaze @yiotaz ^^