Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everyone is wrong about that Slack flowchart

sophiebits.com

Post reply on HN
Print view View original

61–70 of 87 posts

Re: Everyone is wrong about that Slack flowchart

#61

Post by lucraft »

kibwen wrote: post #9

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…

> 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.

Re: Everyone is wrong about that Slack flowchart

#62

Post by hkon »

Terr_ wrote: post #46

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.

is typing... zzz

Re: Everyone is wrong about that Slack flowchart

#63

Post by jgalt212 »

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.

Re: Everyone is wrong about that Slack flowchart

#65

Post by kccqzy »

puzzledobserver wrote: post #11
VyseofArcadia wrote: post #10

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?

I disagree. Having read the original diagram, I believe it does a very good job of making precise what user intuition says the software should behave.

Re: Everyone is wrong about that Slack flowchart

#66

Post by wbl »

alextingle wrote: post #55
wbl wrote: post #38

Earlier quoted context omitted.

Until you have the feature in production you do not know if it works.

That whole approach is so disrespectful of users. If you are a serious business, then hire sufficient QA people, and empower them to do their job. Expecting your customers to do your QA for you is super common these days. But that doesn't make it right. (What really infuriates me is the general lack of feedback channels that enable users to actually contribute to QA. With open source software, end users can at least…

QA has the disadvantage of knowing how it should work. Users are not so burdened and very creative.

It can decrease the chances but isn't a panecea.

Re: Everyone is wrong about that Slack flowchart

#67

Post by MichaelZuo »

coldtea wrote: post #58
kibwen wrote: post #9

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…

> 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…

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.

Re: Everyone is wrong about that Slack flowchart

#68

Post by coldtea »

MichaelZuo wrote: post #67
coldtea wrote: post #58

Earlier quoted context omitted.

> 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…

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.

>That’s not reducing complexity at all though, just hiding it…

It's a representation. The actual thing will still have the whole complexity.

What is reduced is how much complexity we take in when looking at what the thing does. When someone wants to get an idea of what the thing does, as opposed to getting into the minutiae of every subcase, such a high level view is a better fit.

Re: Everyone is wrong about that Slack flowchart

#69

Post by MichaelZuo »

coldtea wrote: post #68
MichaelZuo wrote: post #67

Earlier quoted context omitted.

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.

> That’s not reducing complexity at all though, just hiding it… It's a representation. The actual thing will still have the whole complexity. What is reduced is how much complexity we take in when looking at what the thing does. When someone wants to get an idea of what the thing does, as opposed to getting into the minutiae of every subcase, such a high level view is a better fit.

Regardless, it's not suitable for those who do need to grasp the entirety...

Re: Everyone is wrong about that Slack flowchart

#70

Post by coldtea »

MichaelZuo wrote: post #69
coldtea wrote: post #68

Earlier quoted context omitted.

> That’s not reducing complexity at all though, just hiding it… It's a representation. The actual thing will still have the whole complexity. What is reduced is how much complexity we take in when looking at what the thing does. When someone wants to get an idea of what the thing does, as opposed to getting into the minutiae of every subcase, such a high level view is a better fit.

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.

Post reply on HN