top | item 41999923

Everyone is wrong about that Slack flowchart

164 points| CharlesW | 1 year ago |sophiebits.com

84 comments

order
[+] kibwen|1 year ago|reply
I don't know if I'd classify the cleaner diagram as "cheating" per se, but it does trade one kind of complexity for another kind. Removing nodes by adding a concept of implicit branches via "unless" clauses within a node doesn't necessarily make the system any easier to understand at a glance. Sometimes systems have good reason to be complex, and sometimes we have good reasons to hide much of that complexity, but let's not conflate hidden complexity with the lack of complexity.

If I were to suggest a way to make the original chart cleaner without changing the quantity of explicit nodes and branches, I would start by reducing it into parts that are cyclic and parts that are acyclic, then drawing clear divisions between those parts. Then you could give these encapsulated bits names and thereby make it easier for them to refer to each other (such as in the duplicated flows between local and global preferences) without having to draw a mess of crisscrossing lines.

[+] NBJack|1 year ago|reply
I agree with you; it is hand-wavey and strays into "spherical cows in a vacuum" territory. Practical for discussions, not so great for implementations, where details matter greatly. I would presume the original diagram was meant to align on the specifics; the revised version from the author leaves much to interpretation.
[+] coldtea|1 year ago|reply
>Removing nodes by adding a concept of implicit branches via "unless" clauses within a node doesn't necessarily make the system any easier to understand at a glance.

It kind of does though, because it's easier to understand what the system does in general without necessarily wanting/needing all the lower level detail.

That's also one of the reasons we use functions, instead of unrolling everything into a big ball of code, no?

[+] lucraft|1 year ago|reply
> Removing nodes by adding a concept of implicit branches via "unless" clauses within a node doesn't necessarily make the system any easier to understand at a glance.

The original diagram does this too - it has an "A && B" node.

[+] IshKebab|1 year ago|reply
I think it's ok to combine simple booleans into one box for the same reason we do that in code.

You generally write `if a and b { foo }` not `if a { if b { foo } }`.

[+] xyst|1 year ago|reply
I just turn off notifications completely. Horribly implemented notification systems have completely turned me away.

DnD on? Nope still get notified. Government sends Amber alert? Yea let’s full send it across the entire state for a crack head vs police incident that occurred 500 miles away at 4AM.

Severe weather alerts have now been moved to voice calls and that number whitelisted in my contacts

[+] sethops1|1 year ago|reply
I see that you also live in Texas
[+] theideaofcoffee|1 year ago|reply
Same, my phone was gradually turning into another point of control over me, rather than the other way around and it being a tool to help me. Only a handful of people are default allowed through DnD, all of the nonsense government alerts are off, almost all app notifications are off save for absolutely the most important ones. If an app somehow breaks through after all of that, it's an instant uninstall, I just don't want to waste any more of my life than I alerady have being subservient to this shit. It's a daily annoyance to have to dismiss popups in apps when they notice they can no longer send notifications. Almost as annoying as the notifications themselves.

Most work apps have a permanent 'Away' status and a message on and the expectation set that I sparingly check throughout the day. It works really well, my mind has never been quieter and more at ease.

[+] VyseofArcadia|1 year ago|reply
Maybe the real source of complexity in that flowchart is there are just too many ways to suppress notifications. You have muting, do not disturb, do not disturb overrides, @message preferences per channel and global, DM preferences, and so on.

I love dials and knobs and sliders in my software, but at some point when they are all for the same feature, there is no longer any way for the user to intuit how they interact.

[+] puzzledobserver|1 year ago|reply
I think this is the real question to ask.

Does the complicated flowchart point to deficiencies in the Slack user interface? If the user cannot intuit the flowchart, then how can they (as several sibling comments rightly point out) reliably turn notifications on or off?

Algorithmic transparency should be a thing, no?

[+] sensanaty|1 year ago|reply
And despite all that, you still can't me @all...
[+] nlawalker|1 year ago|reply
> To me this is way easier to understand.

> I know this is not 100% bug-for-bug compatible with the original flowchart.

“For every complex problem there is an answer that is clear, simple, and wrong.” (https://quoteinvestigator.com/2016/07/17/solution/?amp=1)

(It’s not my intent to be totally dismissive, the author has good points, but I couldn’t resist the pithy but misquoted quote)

[+] Terr_|1 year ago|reply
A separate gripe: Still no support for "batching up" a trickle of notifications from a particular DM/channel, which is especially frustrating on the phone-app.

*bzzzt* You probably met him, that one guy

*bzzzt* who sends messages like this

*bzzzt* and each time your phone vibrates for attention

*bzzzt* but you never needed to know that soon anyway.

[+] redrove|1 year ago|reply
bzzzt Hello

* waits 20 minutes *

bzzzt How are you?

* waits 3-24h *

bzzzt Can you help me with XYZ?

I answer ASAP

I hate these people. It’s such a drain on my mental well being.

[+] saagarjha|1 year ago|reply
I wish my OS did this. And no, not with a LLM “summary”. Just literally rate limit the notifications.
[+] hkon|1 year ago|reply
is typing... zzz
[+] dakiol|1 year ago|reply
I can’t work with notifications enabled. Every hour I work, I make a 15 min pause or so and then I check Slack and answer if needed. Not just Slack, I don’t have any notifications enabled. I always pull. The only exception is phone calls.
[+] ivewonyoung|1 year ago|reply
I wish I could do that but rarely I do get something that needs my attention immediately because I don multiple hats including Infrastructure,SRE,DevOps,SysOps,programmer etc.
[+] yaro330|1 year ago|reply
Every time I see this flowchart I get reminded that Slack casually sends half of my notifications to a sleeping/disabled laptop instead of my phone.

I also get reminded that Telegram has one of the simplest notification schemes in existence. Notify last used device -> If still unread after ~30 seconds notify every logged in device. That's it, dead simple, never missed a TG notification.

[+] akkad33|1 year ago|reply
Or phone ringing violently minutes after I've already picked up the call on my laptop
[+] ncr100|1 year ago|reply
Lol I rarely received notifications that I expect to. (I've checked my settings and done nothing else to fix it, not tried reproducing behavior nor reporting it to Slack.)

Paid server.

Android client.

Lightly used, in part due to the absence of notifications.

It's been over a year that I've missed notifications. More than 50% missed, comments to my threads especially, and also new messages on watched channels.

[+] orf|1 year ago|reply
A notification in this context isn’t a push notification, it’s a Slack notification (a red bubble counter).

Sounds like an issue with your android phone.

[+] chatmasta|1 year ago|reply
Do you have a bot or script somewhere that’s using your token and appearing to “read” messages before you see them yourself?
[+] Kwpolska|1 year ago|reply
Flowcharts tend to suck when trying to describe anything remotely complicated. I doubt anyone is seriously using the original flowchart to get any work done, the actual code must be more readable, and would be guaranteed to be correct.

On the other hand, overloading a flowchart with things like "unless" or "including" makes it harder to follow.

[+] XorNot|1 year ago|reply
That flowchart is absolutely what happens when a bunch of programmers got told to "draw the complete system" in one diagram - which is absolutely not how it should've been represented.
[+] luke_galea|1 year ago|reply
I think the slack flowchart is a great example of where declarative programming really shines.

You might enjoy this talk about rules engines where I simplify part of Slack's notification logic: https://youtu.be/mDnntrhk-8g?si=K1_8pU-Ck1fsCUM5

Fun stuff!

[+] psd1|1 year ago|reply
I will invest that time later. In anticipation, thanks.

I came here to see if anyone was talking about state machines that generate their own flowcharts, or codegen from flowcharts. I'd like to know if there's prior art.

It would be great for user acceptance. I'm minded to have a go myself, possibly with mermaid as an intermediate description. Stupid? Non-stupid?

[+] LudwigNagasena|1 year ago|reply
I look at the first flowchart and think to myself, were all the product managers, business analysts, and UX designers drunk when all of that was getting implemented?
[+] ziml77|1 year ago|reply
No. People just interact with these messaging systems in a variety of ways and the notification flow here has to account for that. Each sender might use @s and threads differently and then the recipients might have different tolerances for what they end up seeing notifications for. If you provide fewer options for the recipients, it's far more likely they'll just blanket disable notifications.
[+] taeric|1 year ago|reply
I didn't see a previous discussion on the flowchart, so I'm not entirely sure why folks were wrong about it.

I do like the updated version. Fun to explore why.

First, it is much much more linear. Effectively top down.

Directions are consistent in outcome. Left is always "don't" and right is "do."

There is no back tracking.

[+] hatthew|1 year ago|reply
guys I simplified it to a single node in a flowchart, this is even simpler right?

(user not DND || message DND override) && ((message in thread && user in thread && user threads_everything) || ((channel notifications everything || (channel notifications unset && global notifications everything)) && ((message not in thread || user in thread) || (message has @channel || (message has @here && user is active)) && @channel messages not muted) || message contains @mention || message contains highlight word || message is on file owned by user))

[+] doctorpangloss|1 year ago|reply
Maybe Slack should stop making an LLM for data mining and chatbots, and instead, deploy an LLM to read a message and determine whether or not you should be notified, because notifications from Slack truly suck.
[+] Inviz|1 year ago|reply
This specific problem is better solved by decomposing the logic into rules that tell when not to send a message. I refactored this diagram once that way, so it becomes absolutely straightforward.
[+] m463|1 year ago|reply
I think slack notifications are complicated, but getting them shows you things you should see, while eliminating garbage distractions.

That said, I still get silly @here and @channel stuff sometime even turned off per-channel, and miss some thread notifications.

So I wish you could color-code channels/messages/threads to know whether you will be notified and let you tweak things if not.

I think a lot of complexity can be visualized and that helps us fragile fallible humans.

[+] teeray|1 year ago|reply
Slack Flowchart: Should we send a notification?

Me: mutes all notifications at the OS for Slack.

[+] jgalt212|1 year ago|reply
That flow chart is crazy. It would be quicker to consider and think about every instance on a case by case basis rather than consult that chart. Snark aside, I do think the flowchart could be useful for the QA team to verify, approve, or disapprove of decisions made by the implementation team.
[+] satisfice|1 year ago|reply
The most important thing to me about the original diagram is that it is underspecified-- you can't determine its meaning just by reading it and also having a basic knowledge of Slack. To understand it you need a close and detailed knowledge of Slack UI and behavior that I don't believe has been officially documented. In fact, I'm left with questions about this diagram I can't answer even after experimenting with Slack.

In other words, there is important tacit knowledge required to interpret the logic.

I wonder if there is an updated version of this available anywhere?

[+] deathanatos|1 year ago|reply
That complexity in the flow chart is probably just straight bugs, like TFA gets into. For example, I'm sure the flow chart — if you made one — for message "parsing" would be similarly complex. And it shows, on the client, since it feels less like there's a parser, and more like someone has cobbled a bunch of regexes together. There's a number of rather trivial to discover bugs¹, particularly around code block formatting and hyperlinks. That Slack will actively mutates entered text is doubly infuriating.

Similarly, complex flowcharts aren't necessarily something to be proud of, rather, something to be eyed with suspicion. Is that complexity essential complexity, or accidental complexity?

(Though sometimes it can be infuriatingly difficult to simplify. I've attacked a few such codepaths in my career only to come out going "nope, it's just that terrible/complex.")

On notifications, one of the best things I ever set up was making my name a notification trigger. Lets me know when people are talking about me (or even to me), but aren't using a @- tag. Some people just … don't seem to know how to do it?

¹trivial enough that it leaves me wondering: does Slack's own eng use Slack, with cognitive awareness of the things that they run into?

[+] isoprophlex|1 year ago|reply
> That Slack will actively mutates entered text is doubly infuriating.

Slack is not good with that but man what are the people smoking that designed MS Teams? What the actual fuck happens when you try to type, copy, paste or send a message?!

Slack is an oasis of sanity, compared.