12 ms·

This backend outage reveals how horrible the Slack UI is implemented. You post a message.... you think it got sent. Then 1min later, it tells you it was not.

notyourwork 6y ago
Just experienced this and decided to context switch to hackernews for a few minutes. Ironic that this post is the top on homepage.
- arbitrage 6y ago
  That's the opposite of irony, as one would absolutely expect weirdness on Slack to be talked about on HN.
  - notyourwork 6y ago
    Broadly speaking maybe, but situationally not really. The likelihood that the issue I'm experiencing is a service wide issue impacting many others is usually low probability.
  - deleted 6y ago
    [deleted]
quietbritishjim 6y ago
The message is in a light grey colour until it's confirmed. I'm not saying it's amazingly obvious but at least the information's there. In fact I'm mostly posting this comment so others know what to look for. (I know this because I just spent 60 seconnds staring at my message trying to figure out why the formatting was off before it told me it wasn't sent. It sent immediately when I retried though.)
- sixstringtheory 6y ago
  I’ve had messages that were black for at least one minute turn gray and only then notify me that they failed to send
  - dopamean 6y ago
    Same
  - znpy 6y ago
    I had sequence of six messages that were not all delivered, and once they were delivered (because I clicked on each one of them) they were re-ordered, altering the my whole part of the conversation.
- deleted 6y ago
  [deleted]
- umanwizard 6y ago
  This is sometimes the case. Not always.
- chimeracoder 6y ago
  > The message is in a light grey colour until it's confirmed. This morning alone, I've had multiple messages start off black, then turn grey after about 10 seconds. And that's not just true today, but other time Slack has been down as well. "If it's black, it's confirmed delivered" is not an invariant.
gomox 6y ago
You can tell it was built for Silicon Valley. The marginally lighter gray tone on unsent messages is only noticeable by design-aware people on fancy IPS monitors. Messages are reordered semi-randomly.
- breatheoften 6y ago
  I frequently send - edit send - edit the same message in an effort to reduce the number of typos. Recently i've realized that this actually introduces more typos -- where a large number of phrases are duplicated or corrected typos reapplied. There's something wrong with slacks operational transform or CRDT implementation or whatever they use to get edited messages to converge
  - paxys 6y ago
    > slacks operational transform or CRDT implementation or whatever they use to get edited messages to converge I'm pretty sure they have none of that, considering you can only edit your own messages. So what's likely happening is that two quick edits are reaching the server at the same time and overriding each other.
    - breatheoften 6y ago
      I could be wrong but i'm relatively sure that I reach message states that do not directly correspond to anything i typed into the editor -- which i wouldn't expect if the edited state was always sent in full rather than as a delta on a previous message state. I suppose it's possible that the corruption happens on the client side tho -- 1. initiate edit action and get editable view of snapshot of text 2. server acks some previous edit request causing some client state related to the message to update and promote a previous edit in some way 3. hit save after finishing editing -- and some delta operation on the client side updates a different message state than the one i initiated edit action from ...
      - viraptor 6y ago
        This is just super unlikely as you describe it. There's no reason for deltas and fancy mechanisms when you can only edit your own messages. It would be a waste of resources to do it like this for short messages.
brundolf 6y ago
It's not an implementation detail, it's a whole (controversial) UX design pattern: https://www.smashingmagazine.com/2016/11/true-lies-of-optimistic-user-interfaces/ https://www.smashingmagazine.com/2016/11/true-lies-of-optimi...
- saagarjha 6y ago
  Optimistic design is good, but you need to also tell the user when you’re being optimistic. iMessage, for example, “sends” a message, but it will also tell you when it’s been delivered so you can check to make sure.
  - Wowfunhappy 6y ago
    Funny story—iMessage on one of my laptops used to very frequently tell me "This message could not be delivered" even though the person on the other end received it fine. (The problem went away after an OS reinstall.)
    - saagarjha 6y ago
      Pessimistic design lets you surprise and delight ;)
      - epicide 6y ago
        It is not delightful to accidentally annoy someone with the same message several times because you thought it did not send.
        brundolf 6y ago
        Pretty sure the GP was /s
- sdflhasjd 6y ago
  It's pretty necessary to inform users when messages haven't sent though, especially when these little failure indicators are hidden in the channels themselves - i.e you need to be looking at the message to know it failed. If I post a message in a channel and go back to work, I don't want to find out later when I check for replies that my message didn't actually send - I need a notification!
onion2k 6y ago
I understand why they use this UI paradigm, but I don't understand why it's not reversed eg make it light grey until the API has confirmed it's been posted. That would maintain the nice 'you posted a message nice and quickly' responsive UI idea, but without making the user angry when it doesn't work. Even if the idea is to fool the user in to thinking Slack is faster than it is, the UI could at least use the reversed 'light grey until confirmed' UI once it's detected that there's a problem. That would make it a bit less tiresome.
- emerged 6y ago
  This morning I sent a message and it was greyed out until finally sending a minute later. So it would seem both cases are possible somehow. Different stages of data propagation?
- ggreer 6y ago
  Ripcord[1] does what you describe. My guess is that Slack doesn't do this because it makes Slack's latency extremely obvious. Even on a great connection, a decent fraction of messages will take multiple seconds to go from gray to black. Apparently even when Slack's API is operating normally, it can take a very long time to respond with, "Your message was received." 1. https://cancel.fm/ripcord/ https://cancel.fm/ripcord/
ljm 6y ago
I was surprised that I couldn't even open up a DM conversation without it blocking on the network - the Ctrl-T/Ctrl-K quick-find just got stuck when I tried clicking on the person's name. Just... how!?
adrianmonk 6y ago
> tells you it was not. At which point there is no option to cancel and say "you know what... don't send it". If you notice it 24 hours later, your choices are (1) be nagged about retrying it forever or (2) retry sending a message that may now be irrelevant. When it comes to retries, the easiest thing for the user is for the software to be responsible for retrying failed actions. Choosing not to do that makes sense IF the goal is to give the user more control because they may not necessarily still want the action done. But if you don't give them that control, it's the worst of both worlds. The retry happens slower, with more manual work, and without the benefit of choice.
- arwineap 6y ago
  I have a DM on mobile with a failed slack message in it that has clogged my UI for months; literally months. On mobile it means that I can't tell if this user has responded to a message or is online at all. I tried telling it not to send ages ago when it actually failed but it hasn't worked, and frankly now it's so far back in history it's impossible for me to try again. I've deleted slack and re-installed to no avail. It's really an awful problem.
- xmprt 6y ago
  Can you not delete the message after it fails?
  - adrianmonk 6y ago
    OK, that's a good question. I can't recall that there's a way to. But I can't reproduce it now to test it and answer definitively.
karmakaze 6y ago
The mismatch between expectation and clearly visible feedback is in the timing. It would be fine if there was a 'still sending' type message after 2 seconds. If this comes up too frequently then the connection is not as reliable as the UI is pretending it to be.
JMTQp8lwXL 6y ago
The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used. The converse is pessimistic rendering: waiting for the server response before updating the UI (and possibly showing a loading spinner in the interim). Facebook Messenger has the best UX paradigm for this I've seen, since it's most graceful in handling the edge case failures while still presenting as optimistic. Your message immediately appears as a conversation bubble, with an icon displaying if the server has received it, an 'X' if it fails (clicking the icon gives you options: re-send, delete, etc), and a read receipt for when the other party views the message. It's a fantastic way of handling the lifecycle. Slack fails because it doesn't communicate that pending, the-server-hasn't-received-it-yet status, and the fallback isn't as graceful.
- flavmartins 6y ago
  It's especially bad if you're on mobile and in an area that might have spotty reception. You post a message, it looks good, you move on. Then later on you come back to it and it was never sent.
  - dimtion 6y ago
    The new Slack on mobile is absolutely unusable. There are no way to know if the interface is up to date, when was the last update or to force an update. The only way I found to know that your message has been received is to have an ack from your interlocutor.
    - ghostpepper 6y ago
      My personal conspiracy theory is that Slack likes the way users "engage" with the mobile app when indicator badges don't clear right away. Often you will open the app because you see the badge, only to realize you've already read the message and the badge just hasn't cleared. They're hoping that you will then click something unrelated in the app, thus increasing "engagement".

notyourwork 6y ago

Just experienced this and decided to context switch to hackernews for a few minutes. Ironic that this post is the top on homepage.

arbitrage 6y ago
That's the opposite of irony, as one would absolutely expect weirdness on Slack to be talked about on HN.
- notyourwork 6y ago
  Broadly speaking maybe, but situationally not really. The likelihood that the issue I'm experiencing is a service wide issue impacting many others is usually low probability.
- deleted 6y ago
  [deleted]

quietbritishjim 6y ago

The message is in a light grey colour until it's confirmed. I'm not saying it's amazingly obvious but at least the information's there. In fact I'm mostly posting this comment so others know what to look for. (I know this because I just spent 60 seconnds staring at my message trying to figure out why the formatting was off before it told me it wasn't sent. It sent immediately when I retried though.)

sixstringtheory 6y ago
I’ve had messages that were black for at least one minute turn gray and only then notify me that they failed to send
- dopamean 6y ago
  Same
- znpy 6y ago
  I had sequence of six messages that were not all delivered, and once they were delivered (because I clicked on each one of them) they were re-ordered, altering the my whole part of the conversation.
deleted 6y ago
[deleted]
umanwizard 6y ago
This is sometimes the case. Not always.
chimeracoder 6y ago
> The message is in a light grey colour until it's confirmed. This morning alone, I've had multiple messages start off black, then turn grey after about 10 seconds. And that's not just true today, but other time Slack has been down as well. "If it's black, it's confirmed delivered" is not an invariant.

gomox 6y ago

You can tell it was built for Silicon Valley. The marginally lighter gray tone on unsent messages is only noticeable by design-aware people on fancy IPS monitors. Messages are reordered semi-randomly.

breatheoften 6y ago
I frequently send - edit send - edit the same message in an effort to reduce the number of typos. Recently i've realized that this actually introduces more typos -- where a large number of phrases are duplicated or corrected typos reapplied. There's something wrong with slacks operational transform or CRDT implementation or whatever they use to get edited messages to converge
- paxys 6y ago
  > slacks operational transform or CRDT implementation or whatever they use to get edited messages to converge I'm pretty sure they have none of that, considering you can only edit your own messages. So what's likely happening is that two quick edits are reaching the server at the same time and overriding each other.
  - breatheoften 6y ago
    I could be wrong but i'm relatively sure that I reach message states that do not directly correspond to anything i typed into the editor -- which i wouldn't expect if the edited state was always sent in full rather than as a delta on a previous message state. I suppose it's possible that the corruption happens on the client side tho -- 1. initiate edit action and get editable view of snapshot of text 2. server acks some previous edit request causing some client state related to the message to update and promote a previous edit in some way 3. hit save after finishing editing -- and some delta operation on the client side updates a different message state than the one i initiated edit action from ...
    - viraptor 6y ago
      This is just super unlikely as you describe it. There's no reason for deltas and fancy mechanisms when you can only edit your own messages. It would be a waste of resources to do it like this for short messages.

brundolf 6y ago

It's not an implementation detail, it's a whole (controversial) UX design pattern: https://www.smashingmagazine.com/2016/11/true-lies-of-optimistic-user-interfaces/ https://www.smashingmagazine.com/2016/11/true-lies-of-optimi...

saagarjha 6y ago
Optimistic design is good, but you need to also tell the user when you’re being optimistic. iMessage, for example, “sends” a message, but it will also tell you when it’s been delivered so you can check to make sure.
- Wowfunhappy 6y ago
  Funny story—iMessage on one of my laptops used to very frequently tell me "This message could not be delivered" even though the person on the other end received it fine. (The problem went away after an OS reinstall.)
  - saagarjha 6y ago
    Pessimistic design lets you surprise and delight ;)
    - epicide 6y ago
      It is not delightful to accidentally annoy someone with the same message several times because you thought it did not send.
      - brundolf 6y ago
        Pretty sure the GP was /s
sdflhasjd 6y ago
It's pretty necessary to inform users when messages haven't sent though, especially when these little failure indicators are hidden in the channels themselves - i.e you need to be looking at the message to know it failed. If I post a message in a channel and go back to work, I don't want to find out later when I check for replies that my message didn't actually send - I need a notification!

onion2k 6y ago

I understand why they use this UI paradigm, but I don't understand why it's not reversed eg make it light grey until the API has confirmed it's been posted. That would maintain the nice 'you posted a message nice and quickly' responsive UI idea, but without making the user angry when it doesn't work. Even if the idea is to fool the user in to thinking Slack is faster than it is, the UI could at least use the reversed 'light grey until confirmed' UI once it's detected that there's a problem. That would make it a bit less tiresome.

emerged 6y ago
This morning I sent a message and it was greyed out until finally sending a minute later. So it would seem both cases are possible somehow. Different stages of data propagation?
ggreer 6y ago
Ripcord[1] does what you describe. My guess is that Slack doesn't do this because it makes Slack's latency extremely obvious. Even on a great connection, a decent fraction of messages will take multiple seconds to go from gray to black. Apparently even when Slack's API is operating normally, it can take a very long time to respond with, "Your message was received." 1. https://cancel.fm/ripcord/ https://cancel.fm/ripcord/

ljm 6y ago

I was surprised that I couldn't even open up a DM conversation without it blocking on the network - the Ctrl-T/Ctrl-K quick-find just got stuck when I tried clicking on the person's name. Just... how!?

adrianmonk 6y ago

> tells you it was not. At which point there is no option to cancel and say "you know what... don't send it". If you notice it 24 hours later, your choices are (1) be nagged about retrying it forever or (2) retry sending a message that may now be irrelevant. When it comes to retries, the easiest thing for the user is for the software to be responsible for retrying failed actions. Choosing not to do that makes sense IF the goal is to give the user more control because they may not necessarily still want the action done. But if you don't give them that control, it's the worst of both worlds. The retry happens slower, with more manual work, and without the benefit of choice.

arwineap 6y ago
I have a DM on mobile with a failed slack message in it that has clogged my UI for months; literally months. On mobile it means that I can't tell if this user has responded to a message or is online at all. I tried telling it not to send ages ago when it actually failed but it hasn't worked, and frankly now it's so far back in history it's impossible for me to try again. I've deleted slack and re-installed to no avail. It's really an awful problem.
xmprt 6y ago
Can you not delete the message after it fails?
- adrianmonk 6y ago
  OK, that's a good question. I can't recall that there's a way to. But I can't reproduce it now to test it and answer definitively.

karmakaze 6y ago

The mismatch between expectation and clearly visible feedback is in the timing. It would be fine if there was a 'still sending' type message after 2 seconds. If this comes up too frequently then the connection is not as reliable as the UI is pretending it to be.

JMTQp8lwXL 6y ago

The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used. The converse is pessimistic rendering: waiting for the server response before updating the UI (and possibly showing a loading spinner in the interim). Facebook Messenger has the best UX paradigm for this I've seen, since it's most graceful in handling the edge case failures while still presenting as optimistic. Your message immediately appears as a conversation bubble, with an icon displaying if the server has received it, an 'X' if it fails (clicking the icon gives you options: re-send, delete, etc), and a read receipt for when the other party views the message. It's a fantastic way of handling the lifecycle. Slack fails because it doesn't communicate that pending, the-server-hasn't-received-it-yet status, and the fallback isn't as graceful.

flavmartins 6y ago
It's especially bad if you're on mobile and in an area that might have spotty reception. You post a message, it looks good, you move on. Then later on you come back to it and it was never sent.
- dimtion 6y ago
  The new Slack on mobile is absolutely unusable. There are no way to know if the interface is up to date, when was the last update or to force an update. The only way I found to know that your message has been received is to have an ack from your interlocutor.
  - ghostpepper 6y ago
    My personal conspiracy theory is that Slack likes the way users "engage" with the mobile app when indicator badges don't clear right away. Often you will open the app because you see the badge, only to realize you've already read the message and the badge just hasn't cleared. They're hoping that you will then click something unrelated in the app, thus increasing "engagement".