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.
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.
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
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.
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.
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?
"Feature flag" development culture is in direct conflict with user's having intuitive, consistent experiences that they can model in their head.
If the vendor needs a database report to see what features the user may encounter in any given session, because it's an n-dimensional matrix that changes based on uncountably many factors, there is no mental modeling to be done. The user just experiences some idiosyncratic amalgam of code in each session, and the vendor watches aggregate metrics to make sure the number of users in immediate crisis remains below some threshold -- bringing in a $XXXX/hr on-call team to identify and apply some adequately impactful change if it breaks over. Meanwhile, the users-in-crisis cross their fingers that the next time they open the app, they get a better roll on the feature matrix and encounter a more tolerable subset of issues.
If you want to be able to understand your software and know how to turn things on and off, you need to demand a whole new (old) approach to building and publishing things. We're way off track right now.
Feature flag development culture is the only practical way to do continuous delivery. The old approach is still used in markets where it makes sense - database systems, for example, often have only a handful of releases per year. But there's a lot of markets where it's just not feasible to make customers wait 3-6 months between when you finish developing a feature and when it's available for use.
> Feature flag development culture is the only practical way to do continuous delivery.
1. That's not true. Even with continuous delivery, you can still just have a sane and mostly stable roadmap that you're betting on, and gradually migrate all your users along it in a cohesive way with thoughtful transitions when any radical changes are needed. Feature flag stuff is a specific approach to product design that took over a lot of engineering teams in the last 15 years. It relies on continuous delivery, for the most part, but continuous delivery is itself completely ambivalent to it.
2. Continuous delivery is rarely necessary in the first place, and almost never in the interest of users. It gained ubiquity as it became first became practical and coincided with product designer's naive enthusiasm for feature flags, but mostly works against user satisfaction by making it hard for users rely on their tools being in a specific condition at any time.
Maybe Continuous Delivery is the problem. What are these markets where customers want such frequent changes? As a user, I don't really want my software changing daily, weekly or even monthly. I don't want features to come and go depending on which arm of an A/B test I am in. I don't want to be part of the developer's "experiment" and metrics-gathering.
Agreed. Speaking as a user, I much preferred when the industry in general had a slower release cadence. I want to update once every year at most, and usually I want to update less frequently than that. Continuous delivery is a thorn in my side.
The actual need for continously delivery is mostly related to running public-facing services at large scale that need the ability to adjust to external events quickly, e.g. when defending against a new form of abuse requires an immediate software change.
Al other software could get away with deliberate release cycles rather than an urge to YOLO things into production. I just think that there is a fallacy in business leadership that ultra short turnaround times on features actually matter for a business.
No individual customer wants frequent changes. They want changes they care about ASAP and changes they don't care about never. But unless I'm maintaining per-customer versions (which can make sense for high value enterprise customers!), promising user X that I won't make any changes until January necessarily means telling user Y that I refuse to resolve their showstopping bug report until January.
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.
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.
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.
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?
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.
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?
> 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?!
I had to turn off my Dark Reader to light mode to see it. Yes, this is a very elegant, easy on the eyes and fun to read website/blog. I would like to use this theme unless it is a fully custom site.
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?
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.
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.
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
I see that you also live in Texas
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.
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.
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.
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?
"Feature flag" development culture is in direct conflict with user's having intuitive, consistent experiences that they can model in their head.
If the vendor needs a database report to see what features the user may encounter in any given session, because it's an n-dimensional matrix that changes based on uncountably many factors, there is no mental modeling to be done. The user just experiences some idiosyncratic amalgam of code in each session, and the vendor watches aggregate metrics to make sure the number of users in immediate crisis remains below some threshold -- bringing in a $XXXX/hr on-call team to identify and apply some adequately impactful change if it breaks over. Meanwhile, the users-in-crisis cross their fingers that the next time they open the app, they get a better roll on the feature matrix and encounter a more tolerable subset of issues.
If you want to be able to understand your software and know how to turn things on and off, you need to demand a whole new (old) approach to building and publishing things. We're way off track right now.
Feature flag development culture is the only practical way to do continuous delivery. The old approach is still used in markets where it makes sense - database systems, for example, often have only a handful of releases per year. But there's a lot of markets where it's just not feasible to make customers wait 3-6 months between when you finish developing a feature and when it's available for use.
> Feature flag development culture is the only practical way to do continuous delivery.
1. That's not true. Even with continuous delivery, you can still just have a sane and mostly stable roadmap that you're betting on, and gradually migrate all your users along it in a cohesive way with thoughtful transitions when any radical changes are needed. Feature flag stuff is a specific approach to product design that took over a lot of engineering teams in the last 15 years. It relies on continuous delivery, for the most part, but continuous delivery is itself completely ambivalent to it.
2. Continuous delivery is rarely necessary in the first place, and almost never in the interest of users. It gained ubiquity as it became first became practical and coincided with product designer's naive enthusiasm for feature flags, but mostly works against user satisfaction by making it hard for users rely on their tools being in a specific condition at any time.
Maybe Continuous Delivery is the problem. What are these markets where customers want such frequent changes? As a user, I don't really want my software changing daily, weekly or even monthly. I don't want features to come and go depending on which arm of an A/B test I am in. I don't want to be part of the developer's "experiment" and metrics-gathering.
Agreed. Speaking as a user, I much preferred when the industry in general had a slower release cadence. I want to update once every year at most, and usually I want to update less frequently than that. Continuous delivery is a thorn in my side.
The actual need for continously delivery is mostly related to running public-facing services at large scale that need the ability to adjust to external events quickly, e.g. when defending against a new form of abuse requires an immediate software change.
Al other software could get away with deliberate release cycles rather than an urge to YOLO things into production. I just think that there is a fallacy in business leadership that ultra short turnaround times on features actually matter for a business.
No individual customer wants frequent changes. They want changes they care about ASAP and changes they don't care about never. But unless I'm maintaining per-customer versions (which can make sense for high value enterprise customers!), promising user X that I won't make any changes until January necessarily means telling user Y that I refuse to resolve their showstopping bug report until January.
I think it more points to how different people behave, and so how channels end up needing different settings to deal with different sets of people.
Sometimes @channel is important, because everyone in the channel knows to use it sparingly.
Sometimes one person just constantly spams @channel in every message.
So you do need different settings.
So you need the nuance to deal with the nuance of people.
And despite all that, you still can't me @all...
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.
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.
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.
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?
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.
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.
Do you have a bot or script somewhere that’s using your token and appearing to “read” messages before you see them yourself?
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.
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?
> 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.
That's because Teams purpose was to replace Skype. You can't replace Skype with a working tool, it will disturb the users.
Content aside (it’s good too), I love this blog and post visually.
I had to turn off my Dark Reader to light mode to see it. Yes, this is a very elegant, easy on the eyes and fun to read website/blog. I would like to use this theme unless it is a fully custom site.
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?