element-hq
App doesn’t tell you in the room list when a message in a room is stuck unsent.
Steps to reproduce
- Send a message in a room with a user with newly unverified devices or some other reason for the msg to be queued.
- Switch away from the room before you see it got queued
- Forget all about it
- 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
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 https://github.com/matrix-org/matrix-spec-proposals/pull/4153 lands.
(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...
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
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
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.
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:
Thanks, very helpful. Doesn't feel like an extra decoration but basically like a special notification, so that's cool. Similarly, the text from the examples feels like what I tried to describe above: a reply from the server, so that's also cool. Obviously, if someone disables such text, that's their choice.
From #4048:
If there an unverified devices present in the room, rather than putting a little red warning on the message, jump straight to the big "Couldn't send" error that happens when you tap on the little red warning.
Also, warn in the roomlist that you have unsent messages.
Especially given policyservs (and SBGs, and quota systems) could also stop your message being sent, WE HAVE TO TELL USERS CLEARLY AND LOUDLY IF THEIR MESSAGE FAILED.
Sorry to reopen but I think the implementation differs from the proposal. Apparently, we now have a text?
So if we do a text, can we please do text that a normal user won't stare at helplessly, but that gives an idea that the app is still working for you? Both, the Teams and the WhatsApp examples above achieve that. They don't do big red warnings plus an error message "Message failed to send" which states an unactionable fact. But they convey that the app is doing something through the clock or by using the text "Sending..."
I understood from @ara4n that the primary worry is to get feedback that the message still has not been delivered. That can be achieved without scaring the user.
The screenshot posted by @ara4n represents the error state that should be an extreme edge case. The app tries hard to send content before ending in this error state
The sending state is pictured in this user story: https://github.com/element-hq/element-meta/issues/2945.
Ah, cool, thanks. That sending looks much better.
But why would an app even end up in this state? Wouldn't it continue to try sending?
But why would an app even end up in this state? Wouldn't it continue to try sending?
Because:
- An SBG or CDG might reject a message due to some policy rule
- The homeserver might reject the message due to some anti-spam or quota or similar policy rule
- There might be some other permenant failure in the room outside our span of control (e.g. unverified devices, prior to MSC4153 landing, or no devices in the room to encrypt for, or, heaven forbid, a bug outside our span of control causing a permenant failure).
(closing given the bug seems to have been reopened based on a misunderstanding)