Clearly indicate that a reply failed to send

[redshiftzero]

Previous behavior when reply failed to send: Entire message box would go red

Current behavior when reply fails to send: Same behavior as success (i.e. it's not obvious from the message bubble that the reply did not send), except after refresh the reply will be gone

It would be good if we could do something that was towards the ultimate reply UX failure scenario (see suggestion to save drafts in #68), but just having the bottom bar in the message bubble go red might be a reasonable thing to do

[ninavizz]

Send failures will reveal both in the Source List, and in the Conversation Pane.
https://scene.zeplin.io/project/5c807ea562f734bd2756b243/screen/5ca3f70f161735068cd01c0a

Not sure what you're referencing as the "Bottom Bar," as that's not been established as a named UI attribute... @creviera?

[ninavizz]

^ n/m, figured it out! Yes, it's spec'd to do the bottom-bar red bit, too. :)

[redshiftzero]

excellent!

[eloquence]

Based on discussions at client sync this morning and with Nina later today, I would suggest splitting this work into 3-4 iterations:

1. General "network error" dialog. Letting the user know that we can't reach the server, and giving them the option to retry all failed operations (starring, replies, etc.). No details about which operation(s) failed.

I would classify this as "must" for beta. This is #391, and a UX design for it is being worked on in this sprint.

2. Inline error annotations without "Retry / Cancel" options. This is essentially the UX specified above, but instead of "Retry / Cancel", it would take you into the same dialog described in 1), e.g., through a "More info" link. From there you would again be given the option to "Retry all" failed operations.

I would classify this as "should" for beta. It is more valuable with a persistent queue. Even in the absence of hard data, it's easy to see that a journalist would ideally like to know which specific reply failed to send.

3. Adding per-reply deletion of failed replies (whether called "Cancel", "Delete" or something else in the UX). This is a relatively low-risk iteration on the above, and would help in cases where a user spots a reply that is no longer relevant.

I would classify this as "could" for beta. Like the per-source/per-reply indicators, it is more valuable with a persistent queue, and most likely to have user value if the user logs in a day later and finds a reply that is no longer relevant that would otherwise be re-sent.

4. Adding per-reply re-sending of individual failed replies.

I would classify this as "won't" for beta. We have insufficient user research evidence to justify it, and it is unlikely we'll be able to do sufficient testing for every edge case scenario in time for the beta.

Each iteration will teach us things we currently don't know, influencing our planning.

Does that approach work for y'all?

[ninavizz]

@redshiftzero To speak to just the styling question you asked on Gitter yesterday... the alpha value on the bubble, in addition to the Urgent Coral coloring of the bar, both change. I included a public Zeplin link, above, but if you log-in to Zeplin you can click on individual attributes to see CSS values. The CSS is the primary value of Zeplin, over PDFs or Invision. The required auth to see that CSS is a PITA, but seeing the CSS is mighty nice.

[ninavizz]

Also: I'll be posting updated wires/protos per the scoping discussion cited by Erik, above, later today. Just FYI. Will ping here, once that happens.

[ninavizz]

Async review materials for my first stab at all this... @redshiftzero @creviera @eloquence.

To cut-down on async chatter in the GH issue (which can be very time consuming), let's postpone discussion until we can all hop on a call & timebox our collective bandwidths?

Feel free to post comments on the GDoc or within Invision directly, btw (not sure if y'all knew you can comment on Invision, on an aside—translucent black tab on the bottom-right, you may need a login, but not a credential I'd trigger or assign).

• GDoc outlining yes/no UI particulars across dev iterations.
• Interactive wireframes, with the usually-kludgey top-page notes/nav things.
  • Some notes on the Invision:
    • The pink text above should all be clickable
    • The windows with "FANCY PANE" in the name reflect a likely v4 or v5 iteration when the user can visibly see they have many choices. I created this for us to consider as context, for when it makes the most amount of sense to say " All," because it's my opinion that feels strange when the user cannot visibly see the "all." We all have a clear mental model of a queue. They are unlikely to even be going there, cognitively—even tho it's nicely hand-waved in deference to.
    • Wireframes do not yet reflect an "Active State" for retrying, deleting, or canceling anything.
      • Tuesday I can share the animation I've been exploring, for a general "Currently connected to and exchanging packets with the server" network activity indicator via modulating the top-barre's gradient values (clearly but elegantly—yes, mindful to not induce seizures).