Improve error handling UX about ajl.ai

[kadamwhite]

Here's the proposed flow I've begun to implement:

• An error occurs within the API
• Client receives the error
• A modal is shown to the user with the error text, a Retry button, and a Restart Workload button
• If user clicks "retry," request is posted again without any change
• If user clicks "restart workload", they go back to the first step of their active workload

Open question: Should the "cancel" option be "new workload," instead?

[boazsender]

Which is the "cancel" option?

I don't think "retry" should be an option. I can't imagine an error state that could be retryable.

I think "request new workload" is the right default.

[kadamwhite]

The two buttons were "cancel" (request new workload) and "retry", sorry that was confusing.

OK; the retry option seemed potentially useful as a fail-safe for timeouts and other types of issue outside our control, but I can omit it.

[kadamwhite]

Re-purposing this issue to handle fleshing out the UX of receiving an API error, as noted above

[boazsender]

This looks good. please test what happens when you loose internet connection.

Please also ad a "start over" action to throw away the workload.

[kadamwhite]

• TEST whether the current error system allows you to retry when connectivity is interrupted
• Also add a default "Start Over" which throws away your work and returns you to the homepage
• (use navigator.online tag?)

[kadamwhite]

If a network error occurs between the initial load of the app bundle and the receipt of the annotations, a Network Error is shown, with a "retry" button. Pressing Retry will re-execute the request.

I'd like to be able to better differentiate between types of error; @gnarf have we considered returning more verbose error objects with unique codes and more status information?