Replies: 2 comments 1 reply
-
I totally agree to that. However, I'm a bit surprised if your UX tests showed that users are confused by technical error messages, because I so far believed to have quite few technical errors. But this could be deployment / infrastructure related in the end.
Makes sense from my perspective.
From DO perspective that's anyway what we internally agreed on. |
Beta Was this translation helpful? Give feedback.
-
|
FYI, I am currently investigating #1762. Regarding T4: currently, all forms are using validation with inline error messages. There could be some rare exceptions, and if one finds such, a ticket should be written. |
Beta Was this translation helpful? Give feedback.
-
|
This introduces a simple error boundary pattern that can be used throughout the UI, to prevent it from crashing in the error situations. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
An early UX test at Bosch has shown that ...
... the current error messages are not user-friendly in the UI. The error messages are often displayed very small at the bottom right (Toast notifications) and are rarely meaningful. In other cases, only white pages are displayed with the text “Something went wrong”. There is no explanation and no back button.
And there already has been a discussion about a similar UX topic here: #1762
I would like to trigger a discussion if we can get consent on the following topics:
T1: Technical errors vs. Business errors
I believe we can agree that it's important to differentiate between technical errors and business errors, and also handle these kind of errors differently from UX perspective.
T2: Handling technical errors (Backend REST API)
Our goal is to minimize technical errors as much as possible. When a technical exception does occur, there is usually little the user can do—aside from refreshing the page in their browser or reporting the issue by copying and pasting the error message.
For communication with the backend REST interface, we use TanStack Query, which provides a built-in error handling mechanism. When errors occur, we display a toast notification that must be manually dismissed by the user.
From my perspective, this is currently an appropriate approach and should be maintained as is.
T3: Handling technical errors (Multi-component Dashboards)
Some UI pages follow a dashboard-like structure and are composed of multiple independent components. A technical failure in one of these components should not cause the entire page to break. Instead, error handling should be scoped to the individual component, rather than applied globally to the whole page.
This approach was already discussed in issue #1762. In such cases, we could make use of CatchBoundary components (docs) to handle errors more gracefully.
Can we agree to move in this direction, handling such decisions on a case-by-case basis, based on incoming issue tickets?
T4: Handling business errors (Forms)
For pages that include forms, validation should follow the approach recommended in the shadcn/ui documentation. When validation errors occur, the corresponding error messages should be displayed directly beneath the relevant input fields.
Can we agree to follow this convention going forward? If this should not be already the case or implemented differently on some UI pages, a bug ticket shall be created to address it.
T5: Handling business errors (other than Forms)
How should we handle other types of business errors? It's not yet clear whether the best approach is to use toast notifications, introduce modal dialog overlays, or display inline messages directly within the UI—similar to how validation errors are shown in forms. At least it should be handled in a uniform way.
Beta Was this translation helpful? Give feedback.
All reactions