You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of now, only a subset of errors are handeled in a way that provides insights to the user. Other errors are handeled very generically. One example of such a generic error message:
Ooops, something went wrong while saving the question...
No info about what's the problem or how to resolve it, while this info is readily available in the response from the API.
A lot of the user-facing errors are handeled with a properly translated message. However, especially when introducing new validations, it would be valuable to be able to provide the user with some non-generic feedback. In the backend, this is done anyway, but the only way to access this as a user is via the dev tools.
There are cases, where the non-translated value would be totally sufficient. Example:
Right now I'm implementing a new validation, that is triggered when saving a TableQuestion. This is done in the FormBuilder and only by one instructed person, who understands English and took part in designing the feature that led to this validation. The validation checks values in the meta of the question. If this validation fails, the API responds with an informative error message, explaining what's the problem. It would improve the experience of a user a lot, if this message could be made accessible to them.
Sometimes, the generic error message is just enough. e.g. if there are errors in the document, that are visually highlighted. We need to make sure, to not replace them with possibly rather cryptic messages from the API.
A lighter approach could be to just implement this for the FormBuilder, where we know we deal with more technical users.
The text was updated successfully, but these errors were encountered:
As of now, only a subset of errors are handeled in a way that provides insights to the user. Other errors are handeled very generically. One example of such a generic error message:
No info about what's the problem or how to resolve it, while this info is readily available in the response from the API.
A lot of the user-facing errors are handeled with a properly translated message. However, especially when introducing new validations, it would be valuable to be able to provide the user with some non-generic feedback. In the backend, this is done anyway, but the only way to access this as a user is via the dev tools.
There are cases, where the non-translated value would be totally sufficient. Example:
Right now I'm implementing a new validation, that is triggered when saving a
TableQuestion
. This is done in the FormBuilder and only by one instructed person, who understands English and took part in designing the feature that led to this validation. The validation checks values in themeta
of the question. If this validation fails, the API responds with an informative error message, explaining what's the problem. It would improve the experience of a user a lot, if this message could be made accessible to them.Sometimes, the generic error message is just enough. e.g. if there are errors in the document, that are visually highlighted. We need to make sure, to not replace them with possibly rather cryptic messages from the API.
A lighter approach could be to just implement this for the FormBuilder, where we know we deal with more technical users.
The text was updated successfully, but these errors were encountered: