App doesn’t tell you in the room list when a message in a room is stuck unsent.

[ara4n]

Steps to reproduce

1. Send a message in a room with a user with newly unverified devices or some other reason for the msg to be queued.
2. Switch away from the room before you see it got queued
3. Forget all about it
4. Hours/days later, return to the room and discover the msg never sent and is stuck in red-warning state, alongside whatever error is stopping it from being sent

Outcome

What did you expect?

I expect a big red ‼️ on the room in the roomlist warning me that something’s wrong with the room and my queued msgs won’t send

What happened instead?

Nothing told me the msg hadn’t sent (short of coincidentally looking at the room), so i waited 6h for a response to a msg which never sent, just because some random user in it had added an unverified device to their acct.

Your phone model

No response

Operating system version

No response

Application version

819

Homeserver

No response

Will you send logs?

No

[ara4n]

This bites me on a regular basis, meaning important message get stuck unsent for days on end.

Given there is always going to be a risk that a message got stuck 'permenantly' unsent (e.g. if a SBG or a server rejects its content), I believe we need UX for this. In other words, this problem doesn't go away once matrix-org/matrix-spec-proposals#4153 lands.

[ara4n]

(It's also a problem on EW, where it just bit me too)

[daniellekirkwood]

(It's also a problem on EW, where it just bit me too)

are you using new room list? you should see "!" on the old one...

[kongo09]

I'm struggling with decorating the room list for something that feels like a bug to the user.

The root cause seems to be that the message is not sent. Either we fix it so that the message is sent, or we block the user flow in that moment, e.g. by a pop-up on send-attempt that the message cannot be sent. If you know for sure that the message never can be sent, it should not be queued either.

Let's not do unactionable warnings

[ara4n]

the problem is the flow when you send a msg, it gets queued due to being offline, and then when its sent the server rejects it due to policy or whatever. we can’t stop that failure mode, rare as it is, and we need to warn the user when it happens, especially if we are trying to train them that they should in general hit send and trust the msg to send, even if offline

[kongo09]

ah, now I understand better. So we just talk about the case where the server doesn't allow the message to be sent.

Again, I'm very dubious about additional decorations. We already have a decoration for something new: a notification. Essentially, what you describe is a reply by the server saying: For this and that reason I cannot accept your message. I'd like to encourage product and design to consider this to be part of the dialogue, essentially a message, maybe inline in the timeline as we know it from WhatsApp and other messengers.

[daniellekirkwood]

Teams

Whatsapp

iMsg

It's hard to test but here's a few screenshots of other phone apps -- each one show you that your message has not been sent. The design proposal is similar to Apple and would be a similar decoration regardless of the screen you're looking at. Remember on Web we can't rely on words (as message previews are off) so personally I think the icon proposed is the right response of "market standard and therefore easy to understand" and "appropriate across platforms"

The proposal:

What we have today: