element-hq / element-android

A Matrix collaboration client for Android.
https://element.io/
GNU Affero General Public License v3.0
3.35k stars 713 forks source link

Aggregations: Handle failures when sending #285

Open manuroe opened 5 years ago

manuroe commented 5 years ago

From riot-web created by jryans: vector-im/riot-web#9692

(see current status below)

manuroe commented 5 years ago

After chatting with @nadonomy about reactions / edits errors in general, we came up with:

Extracted from Editing / Reactions UX doc.

manuroe commented 5 years ago

But I'm not sold on the wisdom of mutating the existing (!) from a 'there are encryption things you should know about' indicator to an iteractive 'there are errors on this message you need to do something about' component - at the very least this will be a tricky migration with many users not discovering the new functionality :\

manuroe commented 5 years ago

@nadonomy's plan above actually covers both reactions and edits, so I'll relabel the issue.

manuroe commented 5 years ago

The edits/reactions/redactions/local-echo work has raised a couple of issues that need rapid resolution:

This is a bigger problem for edits and redactions than it is for reactions (it is considered generally more important for a user to know if an edit or redaction has failed to persist than a reaction)

@nadonomy's proposal above is certainly worth exploring; in his absence though I'd like us to consider the simplest possible change we can make to convey the missing information. This is a proposal for what that might look like:

The ⋮ menu should then have the any necessary resends available as a context-menu option - resend edit, resend redaction, or resend reaction

We'd also need to modify the wording of the error message; something like:

Some of your messages, edits, reactions or redactions have not been sent.

[Resend all]() or [cancel all]() now. You can also select individual messages to resend or cancel pending actions.

manuroe commented 5 years ago

My motivation for the above was to see how far we could get stretching the existing 'faded == pending, red == failed' language to edit, reactions and redactions. At this stage in my thinking I am very much not convinced that stretching the existing language is the right approach - it could be that an 'error icon' based approach is clearer and simpler to implement.

manuroe commented 5 years ago

Also I just remembered that red == mentioned as well as red == failed, so I'm even less convinced that stretching red to cover all these sorts of failures is a good idea.

manuroe commented 5 years ago

Notes from group discussion:

manuroe commented 5 years ago

After another round of discussing, including Matthew, we landed on: