Should chat input box block typing when sending?

shpuld commented

2020-09-03 09:18:24 +00:00

Owner

So currently chat input box uses same post status form which blocks all interaction while it's sending, it makes sense for statuses. When chatting you often want to start typing the next message immediately after hitting enter, but this mechanism blocks it, it becomes very clunky.

The challenge is handling posts that fail to send if we unlock the form immediately. they'd have to retry sending a few times and somehow indicate that they haven't been sent.

So currently chat input box uses same post status form which blocks all interaction while it's sending, it makes sense for statuses. When chatting you often want to start typing the next message immediately after hitting enter, but this mechanism blocks it, it becomes very clunky. The challenge is handling posts that fail to send if we unlock the form immediately. they'd have to retry sending a few times and somehow indicate that they haven't been sent.

eugenijm commented

2020-09-03 13:36:54 +00:00

Member

The challenge is handling posts that fail to send if we unlock the form immediately. they'd have to retry sending a few times and somehow indicate that they haven't been sent.

This can probably be done by introducing optimistic posting (with the help of the idempotency key) and keeping track of each message (e.g., (sending | delivered | error)) and styling them accordingly, I think. But BE would need to broadcast the idempodency key via WS too since sometimes the WS event can arrive earlier than the HTTP response and such event would be taken as a different message.

> The challenge is handling posts that fail to send if we unlock the form immediately. they'd have to retry sending a few times and somehow indicate that they haven't been sent. This can probably be done by introducing optimistic posting (with the help of the idempotency key) and keeping track of each message (e.g., `(sending | delivered | error)`) and styling them accordingly, I think. But BE would need to broadcast the idempodency key via WS too since sometimes the WS event can arrive earlier than the HTTP response and such event would be taken as a different message.

shpuld commented

2020-09-03 13:57:00 +00:00

Author

Owner

We could maybe do it simpler without needing extra support, we don't block the entire form but just block send, so that user can start typing the new message before the previous one has sent but just can't post it, I think it would totally eliminate the biggest issue we have with it currently.

hj commented

2020-09-03 14:33:56 +00:00

Owner

Blocking text input while sending is a terrible, terrible UX. People often type message, hit ENTER (or SEND/send shortcut i.e. ctrl-enter) and keep on typing next message. Disabling text field would make it lose focus, which will cost user some keystrokes going into the void (and pray mercy they aren't using VimFX/SakaKey/Vimperator or similar addons), not to mention we will probably need to re-focus it after it becomes enabled which could be pain.

hj commented

2020-09-03 14:34:25 +00:00

Owner

I think Riot did something like that and it was horrible.

shpuld commented

2020-09-03 14:35:57 +00:00

Author

Owner

yes it's bad, that's what we're doing right now, changing it has it's own drawback why the issue

hj commented

2020-09-03 14:37:49 +00:00

Owner

this feels like a crutch. Sure we can block send, but what if message errors out, what do we do? Erase new draft and put old one instead? Let errored message go into void? Show error "your message: $MESSAGE was not sent" so that user can copy it?

IMO having chat bubble with "not sent, click to retry", while being an awful situation is still best UX out all known solutions.

this feels like a crutch. Sure we can block send, but what if message errors out, what do we do? Erase new draft and put old one instead? Let errored message go into void? Show error "your message: $MESSAGE was not sent" so that user can copy it? IMO having chat bubble with "not sent, click to retry", while being an awful situation is still best UX out all known solutions.

shpuld commented

2020-09-03 14:49:18 +00:00

Author

Owner

retry the message until it sends is my first solution, if the connection is borked you're not gonna send anything more anyway

alexgleason commented

2020-09-03 15:53:34 +00:00

Member

In Soapbox FE we push a fake message into the chat as soon as the user sends, and then it gets overridden with the real message on response. It gives a UUID to this fake message so it can keep track. It feels fast.

In Soapbox FE we push a fake message into the chat as soon as the user sends, and then it gets overridden with the real message on response. It gives a UUID to this fake message so it can keep track. It feels fast. ![Screen_record_from_2020-09-03_10.52.45](/attachments/543bb578-be2c-4da5-b875-106b75369bdc)

Screen_record_from_2020-09-03_10.52.45.mp4

87 KiB

shpuld commented

2020-09-03 15:58:24 +00:00

Author

Owner

yeah that's really nice, I'd like to have something similar

what does it do when it fails to send?

yeah that's really nice, I'd like to have something similar what does it do when it fails to send?

alexgleason commented

2020-09-03 16:02:37 +00:00

Member

It stays semi-transparent. It should probably turn red and maybe have a "Try resend?" button.

hj commented

2020-09-03 16:02:57 +00:00

Owner

you still want to type a draft because connection can come back soon.

shpuld commented

2020-09-03 16:04:59 +00:00

Author

Owner

yeah you can type the draft for the next post, just not send it

lambadalambda commented

2020-09-03 16:10:55 +00:00

Owner

This really seems like a good solution, we should probably just do the same.

shpuld commented

2020-09-03 16:13:05 +00:00

Author

Owner

automatic retry is what I'd try first when it fails to send

lambadalambda commented

2020-09-03 16:14:58 +00:00

Owner

automatic retry really should be enough, if it fails just let it fail and mark as red or something, the user can send new message.

eugenijm commented

2020-09-07 10:45:46 +00:00

Member

Looks nice.

A small note. It seems that right now SoapboxFE doesn't sync your own messages when the same chat is opened in different tabs. Since PleromaFE does the sync, the same approach makes duplicate messages being added due to not being able to associate the fake message with the one coming from the WS streaming if it arrives earlier than the HTTP response.

More specifically:

When the user sends a new message,

The fake message is added to the list.
The WS streaming pleroma:chat_update event for that message arrives earlier than the HTTP response. Since it doesn't contain the fake id and can't be associated with the request/response cycle, it can't replace the fake message and so the duplicate message is created.

I think we would need to broadcast something like the idempotency key via the pleroma:chat_update streaming event so that we could associate the fake message with the one coming from the WS streaming event and avoid the duplicates. This way clients can do both the sync and the optimistic posting.

Looks nice. A small note. It seems that right now SoapboxFE doesn't sync your own messages when the same chat is opened in different tabs. Since PleromaFE does the sync, the same approach makes duplicate messages being added due to not being able to associate the fake message with the one coming from the WS streaming if it arrives earlier than the HTTP response. More specifically: When the user sends a new message, 1. The fake message is added to the list. 2. The WS streaming `pleroma:chat_update` event for that message arrives earlier than the HTTP response. Since it doesn't contain the fake id and can't be associated with the request/response cycle, it can't replace the fake message and so the duplicate message is created. I think we would need to broadcast something like the idempotency key via the `pleroma:chat_update` streaming event so that we could associate the fake message with the one coming from the WS streaming event and avoid the duplicates. This way clients can do both the sync and the optimistic posting.

root added the

Better behavior

Discussion

labels

2026-02-06 06:32:48 +00:00

Rows
Columns

Should chat input box block typing when sending? #948