[replies] improve reply failure UX when reply failed to send

[redshiftzero]

For the following reply user story:

As a journalist, I want my reply draft to be saved if it doesn't send properly such that I don't have to retype it.

which was previously part of #16, it makes sense to think a bit more about the UX implications prior to implementing it. One suggestion in #16 was to:

if failure: remove row from reply table locally, important from user perspective: move the reply text back to the compose reply area in the UI otherwise they will lose their draft

@heartsucker suggested another possibly better UX ways to do this, such after a few retries we adopt the as Signal-like behavior, where the reply appears in the message flow, but with an "X" on it such that it is clear it did not send.

[ninavizz]

So, I'm seeing two pattern approaches, above.

Pattern 1: Reply fails to send, so the text remains in the "Compose Reply" window for that Source.
Pattern 2: Reply fails to send, so we publish reply in message flow but treated to clearly indicate it did not send and offering the option to try re-sending or deleting. This is not only used by Signal, but is also how SMS' are handled in iOS, and how other mobile messaging apps do things, too.

For a multi-user system, I think Pattern 2 is the best option. It would look strange for Jane to compose a reply that fails, and then Joe signs-in and sees Jane's text in the "Compose" field. We'd also have to attribute that to Jane in the "Compose" field, which should always/only reflect text the currently signed-in user has put there.

I'd love to get a nicely thought-out version of this built into the prototype and to run it by users. I think a lot of ideas have come-up in the past week, and I'd also like to take a time-out from Findings Reporting and prototype building, to jot all these down.

In the meantime: yes, my vote would be to go ahead and build Pattern 2 into the Client UI, with some different visual treatment to indicate it had not sent; the option to re-send; and the option to delete the whole thing. I love how much y'all care about how our users experience things! <3

[heartsucker]

So my initial concern with what you proposed is that it feels like we are mixing email and chat with how this behavior works.

Email is:

• Write message
• Hit send
• On error, a "can't send, save to drafts?" message or try again
• Multiple emails are not usually sent in quick succession

Chat is:

• Write message
• Hit send
• Message appears in chat UI as sent/sending
• On error
  • notify and allow resending
  • OR just keep trying forever but allow cancellations
• Multiple chat messages are sent in quick succession

Right now the client feels like a chat app, so we should take either the WhatsApp approach (keep trying until the message actually sends, strict ordering of sent messages) or the Signal approach (try a few times, allow out of order messages).

I am strongly in favor of the WhatsApp approach because communication is meant to be received in the order it was spoken/sent, not the order the computer managed to shoot it off.

[eloquence]

@heartsucker It's not quite clear who you're responding to with "what you proposed". It seems to me that the pattern @ninavizz suggests is consistent with the chat-based pattern you describe -- basically in-place retry/cancel in the messaging flow.

If we don't do automatic re-delivery (which seems difficult to get right, especially in combination with manual cancel), then the main queuing problem I see is making sure that retries are handled sequentially, i.e., if user clicks retry 1, retry 2, retry 3, the delivery sequence should be 1, 2, 3, not 3, 1, 2 or whatever the API timing results in. But if the user clicks 1, 3, 2, and the recipient gets 1, 3, 2, I don't think that's a big deal.

The other UX problem I foresee if there's significant latency is just making sure that users notice delivery errors. There might have to be an error indicator in the list view, so that even if you move along to another source, you can notice that a previous one had delivery errors.

[ninavizz]

It's rough. By rough, I mean it's ROUGH... but, check it out:
https://projects.invisionapp.com/prototype/SD-IWS-OpenOops-cjnpmazdx00flvk01ik6y2dhl/play/0cf6509e

• Click desktop icon
• Click signin link
• Watch (cough, it's rough!); see top-left messaging, see contextual activity messaging.
• Click "Retry"
• Watch; see top-left activity messaging, see contextual activity messaging.

[ninavizz]

@heartsucker A few thoughts...

1. This is a shared workstation. So, data is saved to the client when Jane uses the workstation, then she turns it off to put it away. The next day Joe boots the machine, and logs on. Jane and Joe both use SecureDrop on tight time-boxed schedule, so may not notice things failed to send and shut-down the laptop, anyway. Of course, we should plan for this in the UX so that Jane is clearly messaged at that time and knows exactly what she's doing—and this issue being flagged, has put that on my radar. But I still think it's good to think through and design/build for this (hopefully) edge-case.

2. If Jane's message fails to send, then Joe is the one likely to successfully re-send it. The newsrooms really function as teams—and thus far, nobody (of 9 users) has cared from whom in the newsroom a message is sent to Sources. Unlike WhatsApp and Signal, this is a client to facilitate communication between a group of people on one end, and an individual on the other end.

SMS and Twitter both handle messages in the order they were actually sent; not the order in which they were intended to be sent. WhatsApp and Signal are also both (exclusively, for the most part) mobile apps, and as such there's an assumption of immediacy in reading/responding that isn't relevant with SecureDrop—so the SMS/Twitter pattern feels more relevant.

I think the proposed pattern above makes sense; and will make the most sense to a Source, receiving correspondence (especially if BenignArtichoke sent a follow-up response between when Jane intended to send her note, and when Joe actually sent Jane's response). Would love to hear your follow-up thoughts.

I'm exhausted, will chat more in the AM!

[heartsucker]

For a multi-user system, I think Pattern 2 is the best option. It would look strange for Jane to compose a reply that fails, and then Joe signs-in and sees Jane's text in the "Compose" field.

I was reading between the lines on this one. A message that didn't send that ends up in the "compose" field after failure seemed to imply the email/drafts pattern I was talking about.

[ninavizz]

@heartsucker Yup. Erik and I discussed the "compose/drafts" bit early on, and decided against it—mostly for the reason you cite, which is that it confuses paradigms and there's likely not much user value in saving drafts, anyway.

[eloquence]

Since October, we've had a lot of conversations about this issue that are not logged here, so just to recap:

• Even with a queue (Add queue for server actions #224), reply-level actions introduce ordering challenges. In addition to the queue order, there's the click order (which reply does the user re-send first), and the source interface order (which reply does the source see first). Resolving this ordering question in consideration of all edge cases is something we want to avoid for the beta.

• We have separate issues for the network activity indicator (Implement network activity indicator #291), which will surface global error state, and for reply-level indicators, to surface reply-level error state (Clearly indicate that a reply failed to send #365). A combination of these two elements (without a reply-level "retry" action), is what we'll likely aim to get done for the beta.

• Post-beta, I would argue that we still need a stronger evidentiary basis before introducing reply-level re-sending functionality, independent of the ordering problem. What real world cases are we solving for with this that are not solved for by global retry combined with reply-level deletion?

To focus the conversation on improvements we're definitely making for beta, I'm removing the milestone from this issue (which is really more of a discussion issue), and closing it; once we have a first iteration of #291 and #365 done, we'll be in a better position to judge if additional iteration is merited. Feel free to re-open if you disagree.