Design Problem: Process Server Logjams, "FYI, this is a thing" and "Error" messaging

[ninavizz]

A user clicks on a new message to read it; the system then needs to mark that message as "Read."
A user then stars that message, and unstars two others.
The user clicks on another new message to read it; the system then needs to mark that message as "Read."
The user composes and sends that Source a response; the response needs to Send.

5 minutes later, the system has been working to process all 6 server comms, and it gives up.
• Should all of these communications between the client and the server be reflected in real-time to the user in the client, as/when they happen?
• When the system throws in the towel, how do we surface that to the user? What do the relevant UI elements do (read/unread, starring, messages sent, etc.)?
• What other use-cases might there be, beyond the below:
• Starring
• Read/Unread indication
• File download
• File export
• File encrypt
• File decrypt
• File delete
• Account delete
• Bulk download/delete actions within an account
• Individual message delete
• Send message to Source
• Message downloads but fails to decrypt
• Messages don't all download upon Refresh
• ???

[eloquence]

This doc contains some initial notes on how network-related issues could be surfaced to the user, based on different scenarios (intermittent failure, permanent failure, deletion on the server).

[ninavizz]

A really, really bad wireframe was created and shared in the UX Meeting 22nd Jan 2019. More broadly this was discussed w/in the context of global activity indicators, and decided to be surfaced in contextual progress/status messaging.

Would still like to bullet-test a TBD prototype against the doc Erik mentioned above, tho.