Workstation Network Failure

[ninavizz]

Problem

How will network activity be shown within the Client?

Considerations

• Each process should have a status "processing" thingamajiggy of some sort—even if subtle
• Multiple processes happening at once shd be represented
• Obvious/major processes should reflect as such to satisfy user need to see actions responded to

Acceptance Criteria

• Simple animation of a scenario that team agrees upon as good-to-go
• Mockup(s) demonstrating possible different states
• Ready to handoff to @creviera

---

This is a sub-task within #31

[eloquence]

Pending:

• colors (part of larger visual design language work) and final design

Likely initially focused on three states: idle, busy, error. See #28 for early design exploration of error flyout.

Actionable:

• first design for error bar at center of top bar

[ninavizz]

First jab at indicating network issues, here: https://projects.invisionapp.com/share/KXS6I4C4QA2#/screens/365077761
• Regular Client pane
• Login pane

Reference this GDoc for differences between Must/Should/Could outlined.

[eloquence]

For reference, the corresponding client issue is freedomofpress/securedrop-client#391, which we should update with the final Zeplin spec when it's ready.

[ninavizz]

MUST: Behavior via Invision · Zeplin

Will post SHOULD and COULD implementation behavior/zep specs next week, once I'm back on the clock... :)

[eloquence]

Thanks @ninavizz! The "MUST" behavior here matches my own understanding of the consensus, which is the deliverable we needed for this sprint, so I'm marking it as done for sprint purposes, but not closing the issue yet.

I think we'll want to treat the "active state" of replies that are enqueued or in the process of being sent as a separate issue from the network error, but it's good to see the two together.

I've updated freedomofpress/securedrop-client#391 accordingly.

[ninavizz]

Both the Login and the main client pane now have network failure indicators. Closing, accordingly.