Page MenuHomePhabricator

Inform users if there was no response from the server
Open, Stalled, MediumPublic


In case of missing signal, or the server not responding to the client anymore, users should be aware that their save may or may not have gone through. Different ues cases are:

  • The network dropping (or changing) mid request
  • The api never responding at all
  • The api responding in a way we don't understand (a malformed response)

In all of these cases, we follow the general error handling pattern, but we want to give a meaningful error message

Acceptance Criteria

  • After TODO seconds of not hearing back from the server, show an error message TODO including it may or may not have been saved!, and that we will not be able to tell them in an overlay to the user as shown in the mock
  • Initially the popup appears on top of the content page (between grey bar and content, if possible, but if not possible, then above the grey bar)
  • Users can scroll content "behind" the popup
  • The error message does not disappear until the error is resolved (successful save, cancel button or leaving the page)

Event Timeline

Lea_WMDE changed the task status from Open to Stalled.May 27 2019, 1:25 PM

We are handling the case "we don't know if the save was successful or not" as one of the instances of the generic "sth went wrong", since we want the same behavior: Once users know that we cannot confirm the save went through, they should be able to edit and save again. In the best case, they save again without any more changes to the item, and are then sure their edit has been published. In the worst case they change something else, the first edit went through, and other people have edited the item in the meantime as well. This would mean the user is working on an old version of the item and might then run into an edit conflict on save.

In the worst case they change something else, the first edit went through, and other people have edited the item in the meantime as well.

I understand the reasoning here. I was particularly thinking about a variant of this scenario: no one else has edited but this user changes his second edit to conflict with his first.

For this reason I was suggesting that that the behaviours for "something went wrong" vs "we don't know if it worked" should differ.
"something went wrong" = still possible to edit text boxes and click publish again.
"we don't know if it worked" = not possible to edit text boxes. Only publish is an option.

We could always do the same action in both situations to compromise on complexity but with the knowledge that in either scenario it might put the user into an inescapable path.

@Tarrow Thanks for the write up!
One more suggestion: Assuming that no one likes to see an error message and we already know, that hitting publish again could solve the issue: Could we automatically hit publish again in the background when we didn't hear back from the server and only if it doesn't work after 3 tries we then let the user know that unfortunately they have to reload because we didn't manage?

@Lea_WMDE this might be a product question as well: How much cognitive load do we need to put on the user for the sake of transparency?