71–80 of 87 posts
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.
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!
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?
Earlier quoted context omitted.
Regardless, it's not suitable for those who do need to grasp the entirety...
Above some point they can just check the code. People looking at flowcharts usually don't need the entirety. Especially as the flowchart could even be out of date, or miss some of the code-level subleties.
And I don’t see why it matters if it’s only a handful of people, information products can still be created for their needs, if so decided.
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?
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?
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.
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.
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!
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?
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.
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.
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.
Earlier quoted context omitted.
Above some point they can just check the code. People looking at flowcharts usually don't need the entirety. Especially as the flowchart could even be out of date, or miss some of the code-level subleties.
Why would those seeking to grasp the entirety use a less efficient and more cumbersome method, than just looking at the full flowchart in the first place? (assuming it exists) And I don’t see why it matters if it’s only a handful of people, information products can still be created for their needs, if so decided.
Earlier quoted context omitted.
Why would those seeking to grasp the entirety use a less efficient and more cumbersome method, than just looking at the full flowchart in the first place? (assuming it exists) And I don’t see why it matters if it’s only a handful of people, information products can still be created for their needs, if so decided.
Because the code is the entirety of the process. Any graph can be wrong, but the code cannot, because it is the implementation. The purpose of a graph is to allow the visualization of the process in an understandable manner. If it doesn't abstract away much from the code, you might as well look at the code directly
Code is not always the same as the process or what the machine actually does... There are hundreds of posible factors from bitflips to a cable getting loose in a socket that could change either.
e.g. There clearly can be a computer configured with enough memory and dense enough memory that at least one bitflip is practically guaranteed in a certain unit time, so the actual process has to include that.
So the code is an abstraction just like the flowchart.