Show replies that have timed out as pending

[sssoleileraaa]

Description

Follow-up issue to draft-replies PR

Right now when a reply fails to send due to a timeout we display it as failed in the GUI and following replies are shown as pending (in a translucent reply bubble) while the queue is paused.

Should replies sent while the queue is paused:

A) show up as pending (in a translucent reply bubble that'll eventually have an animated progress icon to show that it's being sent)

B) show up as failed (in a reply bubble that has a red bar to show that it actually isn't being sent)

C) show up as drafts that can't be sent because of the network issue (so not the translucent in-progress state, not the red-bar failed state)? Also, should we disable the "Send" button and instead have a "Save" button when the queue is paused? Should the entire reply box be disabled?

---

UPDATE as of 2/19/20

We decided that for the pilot we are going to stick with option A above (without plans for an animated progress icon): replies sent while the queue is paused will continue to show up as pending. In addition, we will no longer show a reply that times out as failed, and instead will show it as pending until the user is logged out or a retry succeeds. Pending indicates to the user that a reply will be retried as soon as the network recovers. Failed indicates to the user that a reply will not be retried.

Note: A user may want to cancel or change a pending reply. Thoughts on this are captured here: #810

[eloquence]

A) show up as pending (in a translucent reply bubble that'll eventually have an animated progress icon to show that it's being sent)

That would be my preferred approach, but a good topic for the next sync w/ Nina. Nina, the context here is that the client is in an error state ("Trouble connecting to the server") but the user sends a reply anyway.

B) show up as failed (in a reply bubble that has a red bar to show that it actually isn't being sent)

I don't think that's correct since the reply should send once the user successfully re-establishes connectivity. It should be in "failed" state if they terminate the client before resolving the connectivity issue.

C) show up as drafts that can't be sent because of the network issue (so not the translucent in-progress state, not the red-bar failed state)? Also, should we disable the "Send" button and instead have a "Save" button when the queue is paused? Should the entire reply box be disabled?

I don't think that's desirable; if we do that for replies, we'd IMO also have to lock other connectivity-dependent features of the client or switch it into offline mode.

[ninavizz]

I'm now in favor of "B"

Why: Current messaging apps take a binary "Doing" and "Done" approach post-send, with "Success" and "Fail" as the two descendants of "Done." Yes, behind the scenes there is a queue working furiously to resolve network issues... but that's not what is surfaced to users. I feel that for now, we should remain consistent with that.

Most email apps do have a global "Drafts" box, and a "Sent" box. Older email clients had an "Out" box that would mark each message as either "Draft" or "Sent."

Zooming-out from this specific use-case, we're also anticipating issues with sync'ing states to the server—namely of read/unread, and starring. Right now, we're not really dealing with starring, as it's speculated to be only a lightly used feature. When read/unread lands, however, that will need to be elegantly addressed wrt connectivity issues—in addition to messages ordered to send, but not successfully sent.

I'm not comfortable with an ambiguous queue of tee'd-up actions to happen, once a connection is re-established; and no visibility into that. Namely, because that will only be a seamless experience if the connection is re-established for the same user with whom the connection was lost. Likewise, I feel that all failed "things" should be handled the same—and I don't see a clear pattern for marking an entire source as "Pending" when it's just the read/unread status that is pending.

The latter, is an especially hazy mental model for most users, because they've been trained for everything to happen automagically—and, most humans don't know what a "state" is (outside the mental model of geography or politics).

Two visions for how this could work, are below. While I don't know exactly "how" would be best to solve for this, I would like whatever we do, now, to elegantly lead-into our future (eg: not train users to expect a radically different behavior).

Offline, involuntary

• Unlike "Voluntary Offline" state, the user will not need to re-authenticate
• Client will return to online state once a connection is re-established
• Once this state is an option, re-thinking "Send" in offline mode should also happen, imho
  

Unresolved Errors Pane

• First proposed ~9mos ago
• To holistically surface allteh fails so user can frame w/in consistent mental model that makes sense
  

[ninavizz]

Adding to epic #650

[eloquence]

Tracking as release blocker because the current behavior (where some failed replies will suddenly send when connectivity is restored) has high potential to be confusing and disorienting.