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.
>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?
That’s not reducing complexity at all though, just hiding it…
Which is fine for someone working a job that doesn’t need to understand all the stuff behind the curtain, but not fine for anyone who actually wants to understand the overall system.
> 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.
From my perspective simple boolean means a single known value stored in one variable. I suspect the underlying code performs a number of calculations for each one of the flow chart "booleans". Of course, maybe that points to a design flaw and there should be a single policy instance that aggregates all of the variables into one place.
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.
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.
I wonder if anyone's done a study on those different styles, clustering them with other things like type of work or personality traits.
I anecdotally associate "those people" with either:
1. Job roles (e.g. Sales) or personalities that are accustomed to interactively pushing people to do things for them
2. People who don't feel safe assuming that I can/will help.
3. Someone struggling to describe their problem up front, so they aren't sure what to place in my metaphorical inbox
4. There are multiple people they could reach out to for help, and they're trying to determine which person might react soonest. (But they aren't using other strategies like posting their problem in a channel and @-mentioning multiple potential helpers.) Their problem may or may not merit the kind of latency they're looking for.
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 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.
I have a second channel for urgent things, which is a phone call. I've told everyone that I'm available whenever, but they need to pick up the phone and call me. Surprisingly that little bit of friction seems to downgrade issues from 'urgent' to 'we can fix it tomorrow'
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.
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.
Readit News
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.
This will vary on the language in which it is implemented, right?
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?
Which is fine for someone working a job that doesn’t need to understand all the stuff behind the curtain, but not fine for anyone who actually wants to understand the overall system.
The original diagram does this too - it has an "A && B" node.
You generally write `if a and b { foo }` not `if a { if b { foo } }`.
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
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.
Dead Comment
Deleted Comment
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?
Algorithmic transparency should be a thing, no?
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.
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.
> 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)
*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.
* 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.
I anecdotally associate "those people" with either:
1. Job roles (e.g. Sales) or personalities that are accustomed to interactively pushing people to do things for them
2. People who don't feel safe assuming that I can/will help.
3. Someone struggling to describe their problem up front, so they aren't sure what to place in my metaphorical inbox
4. There are multiple people they could reach out to for help, and they're trying to determine which person might react soonest. (But they aren't using other strategies like posting their problem in a channel and @-mentioning multiple potential helpers.) Their problem may or may not merit the kind of latency they're looking for.
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.
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.
Sounds like an issue with your android phone.