[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Page MenuHomePhabricator

Ensure the user that the app did not crash while data is retrieved
Closed, ResolvedPublic

Description

As an user, I want to be sure that the web app did not crash.

Problem:

When the user clicks the button to "assess item quality" the data is requested from the API, which might take some (hopefully short) time.

Solution:

  • Show a waiting state, ensuring the user that the app did not crash and that it is working.
  • Avoid introducing unclear states by blocking UI parts
  • In case of a crash the data entered should still be copy-paste-able

Screenshots/mockups:

image.png (238×506 px, 14 KB)

BDD
GIVEN input of IDs on the first page
WHEN clicking "assess Item quality"
THEN the button shows as "progress" indicator in front of the label
AND the button is deactivated
AND the text field is deactivated but it is still possible to copy paste from it

Event Timeline

I have also added the following alert if there was an issue with getting a response or processing the responses from the API:

image.png (370×769 px, 23 KB)

That makes sense.

@Lydia_Pintscher is there a place where we can people link to to find out what happened and when it will be back online?

Looking good! One small thing:

I have also added the following alert if there was an issue with getting a response or processing the responses from the API:

image.png (370×769 px, 23 KB)

It seems words there are switched. "An error occurred while processing your request." ?

That makes sense.

@Lydia_Pintscher is there a place where we can people link to to find out what happened and when it will be back online?

Not yet. I think we should solve this with T275993.

Not yet. I think we should solve this with T275993.

It would make sense to provide some way forward in the error message. I don't know what causes such errors typically. It might be helpful if we add "please try again later" or "have a look at [LINK]" (Based on #9 of the Nielsen Interface Heuristics)

I will offer another suggestion also, the user can directly report the issue to the GitHub project and capture the error messaging from the application.

For example: "Click here to report the issue"

This may be problematic for users who don't have Github but would like to get your thoughts anyway.

This may be problematic for users who don't have Github but would like to get your thoughts anyway.

Yes, I think for non-developers (which, I think are the tool’s target group) this is not very helpful (thought I am not against having the possibility somewhere were it is not drawing attention for the main target group)

I will offer another suggestion also, the user can directly report the issue to the GitHub project and capture the error messaging from the application.

For example: "Click here to report the issue"

This may be problematic for users who don't have Github but would like to get your thoughts anyway.

We shouldn't ask Wikimedians to report issues on github though :/ If we can get the same data to a phabricator ticket that'd be ideal.

Lets split the "other developers should be able to report problems" in a separate ticket; as we should do with "have a error message that provides helpful guidance to problem solving (for non-developers)"

It is possible to create a bug report in Phabricator in a similar way. Would this come under a 'Bug report' or 'Production Error' ?

Review notes:

Change text to An error occurred while processing your request with a report option to Phabricator as a New Task

Isn’t the most likely reason for an error that the WiFi is flaky?

The error could appear if:

  • There was a problem connecting to the Wikidata API or ORES API (could be WiFi or the service is down)
  • There was a problem parsing the results from the APIs (purely internal to the application)

Can we distinguish the problems? Cause then we could have:

"There was a problem connecting to the service. Please check your internet connection or try again later"

"There was a problem parsing the results from the APIs. This is probably a problem with our code. If you know how, report the issue at [link]"

Yep, we should be able to detect if its an error from a service vs. something internal in the application and have different messaging.