5 ms·

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

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 2y ago
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?
- swatcoder 2y ago
  "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.
  - SpicyLemonZest 2y ago
    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.
    - ryandrake 2y ago
      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.
      - SpicyLemonZest 2y ago
        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.
        Nullabillity 2y ago
        You can backport bugfixes if they're critical enough.
      - gmueckl 2y ago
        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.
- mattmanser 2y ago
  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.
- kccqzy 2y ago
  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.
sensanaty 2y ago
And despite all that, you still can't me @all...

puzzledobserver 2y ago

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?

swatcoder 2y ago
"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.
- SpicyLemonZest 2y ago
  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.
  - ryandrake 2y ago
    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.
    - SpicyLemonZest 2y ago
      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.
      - Nullabillity 2y ago
        You can backport bugfixes if they're critical enough.
    - gmueckl 2y ago
      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.
mattmanser 2y ago
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.
kccqzy 2y ago
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.

sensanaty 2y ago

And despite all that, you still can't me @all...