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
{{ message }}
This repository has been archived by the owner on Aug 29, 2023. It is now read-only.
From a developers' perspective the information provided is good ; an exception has been caught on the Task attempting to do something which it should not be doing, and the developer is informed of the failure. A callstack is provided.
But, from a (non-developer) user's perspective it gives the impression that the toolbox is broken.
Although the reasons for the toolbox not succeeding in performing the task are correct, (1) the word "failure" and (2) phrase "raised exception", (3) the colour red-triangle, and (4) big red toast, give the impression that the user asked the Toolbox to do something legitimate and the toolbox failed to do so as its broken.
I suspect there are many scenarios such as this, other than the coregister example (see screenshots).
My suggestion would be - Where exceptions are legitimately raised because the operation is being used incorrectly, this is an opportunity to educate or guide the user. To that end -
(1) the word failure could be replaced with something less harsh, like a friendly 'ooops' type message saying the toolbox couldn't carry out the request because ....
(2) the "raised exception" message be phrased as a reason why the operation could not take place, then followed by the exception-text ("The slave dataset grid is not equidistant..."). The "Details" link would be there for the developers to see the details.
(3) The big red dialog with text starting 'failed' could be a different colour (something other than red). A colour indicative that we're helping and guiding the user. Perhaps a yellow-background like a post-it note? - anyway, something other than red.
(4) similarly, the red triangle is a little unfriendly if we're trying to inform and guide the user.
I think this approach would (1) keep the developer details still there, through 'details' (e.g. call stack), and (2) shift the user impression of the toolbox to be a bit more supportive to the user.
Hot to recreate - see screenshots. Load two datasets; see screenshots for details. Co-register operation causes exception.
The text was updated successfully, but these errors were encountered:
esacci
changed the title
User Informed of "Raised Exception"s Rather Than Gracefully Informing User That Task Cannot be Performed.
User Informed of "Raised Exception"s Rather Than Gracefully Informing User.
Mar 26, 2018
Thanks for your input Ed, very welcome! We'll consider your suggestions when fixing #393. Btw, we'll have a DevTC tomorrow regarding all the Cate issues related to error raising, handling, and reporting.
Mac dev7.
Similar to #589.
From a developers' perspective the information provided is good ; an exception has been caught on the Task attempting to do something which it should not be doing, and the developer is informed of the failure. A callstack is provided.
But, from a (non-developer) user's perspective it gives the impression that the toolbox is broken.
Although the reasons for the toolbox not succeeding in performing the task are correct, (1) the word "failure" and (2) phrase "raised exception", (3) the colour red-triangle, and (4) big red toast, give the impression that the user asked the Toolbox to do something legitimate and the toolbox failed to do so as its broken.
I suspect there are many scenarios such as this, other than the coregister example (see screenshots).
My suggestion would be - Where exceptions are legitimately raised because the operation is being used incorrectly, this is an opportunity to educate or guide the user. To that end -
(1) the word failure could be replaced with something less harsh, like a friendly 'ooops' type message saying the toolbox couldn't carry out the request because ....
(2) the "raised exception" message be phrased as a reason why the operation could not take place, then followed by the exception-text ("The slave dataset grid is not equidistant..."). The "Details" link would be there for the developers to see the details.
(3) The big red dialog with text starting 'failed' could be a different colour (something other than red). A colour indicative that we're helping and guiding the user. Perhaps a yellow-background like a post-it note? - anyway, something other than red.
(4) similarly, the red triangle is a little unfriendly if we're trying to inform and guide the user.
I think this approach would (1) keep the developer details still there, through 'details' (e.g. call stack), and (2) shift the user impression of the toolbox to be a bit more supportive to the user.
Hot to recreate - see screenshots. Load two datasets; see screenshots for details. Co-register operation causes exception.
The text was updated successfully, but these errors were encountered: