I work at Stack Overflow, where our company chat is split between Slack and an internal chat product we made ourselves years ago.
I think the "comments as threads" concept helps solve some specific use cases (like room clutter) but not the use cases I personally care about the most.
My gripe doesn't stem from rooms being too cluttered, it stems from if there are 4 people talking at once and I'm in two different conversations chains with them, I'd like to explicitly reply to a specific message and carry on the convo. not hide it in a comment thread.
On our homebuilt chat product this is the difference between starting a message with `@Name` or hitting "reply" on a specific message and having `@:{Message Id}` as the beginning of your message.
It shows the same to the users, they seen `@Name`, but if it's a specific message reply when they hover over the message the one it's in response to gets highlighted (and there's a button to scroll to it if it's off-screen).
I think this Slack feature, like most features, is targeted at helping people using chat sitting in the same room or office together.
I work at a very remote company where with some people I share less than 2 hours of a work day. I want better chat tools centered around making our async communication flow better. Not out-of-room comment threads.
It would be quite amusing if it couldn't work with AD, considering Zulip is based on Zephyr which is a very old chat protocol/application heavily dependent on Kerberos.
Just FYI, Zulip uses a similar UI model to Zephyr, but doesn't use the Zephyr protocol internally. (For example, Zephyr doesn't really work when one user is behind a NAT)
(I worked for Zulip, and have contributed to the open-source project)
>The "in-line method" mentioned in this [FastCompany] article about the change is my preferred method:
My gripe doesn't stem from rooms being too cluttered, it stems from if there are 4 people talking at once and I'm in two different conversations chains with them, I'd like to explicitly reply to a specific message and carry on the convo. not hide it in a comment thread.
It's fascinating that the preferences for "flat view vs thread view" get revisited in newer software. Fyi, Jeff Atwood blogged about this 10 years ago in 2006.[1]
Thank you for linking that FastCompany article because it emphasizes that Slack's distinguishing rationale was to visually place threads in a different area of the screen. Whether that proves to be the best tradeoff between flat-vs-thread remains to be seen in the marketplace of ideas.
Comments
I agree wth this comment a lot.
I work at Stack Overflow, where our company chat is split between Slack and an internal chat product we made ourselves years ago.
I think the "comments as threads" concept helps solve some specific use cases (like room clutter) but not the use cases I personally care about the most.
The "in-line method" mentioned in this other article about the change is my preferred method: https://www.fastcompany.com/3067246/innovation-agents/the-un...
My gripe doesn't stem from rooms being too cluttered, it stems from if there are 4 people talking at once and I'm in two different conversations chains with them, I'd like to explicitly reply to a specific message and carry on the convo. not hide it in a comment thread.
On our homebuilt chat product this is the difference between starting a message with `@Name` or hitting "reply" on a specific message and having `@:{Message Id}` as the beginning of your message.
It shows the same to the users, they seen `@Name`, but if it's a specific message reply when they hover over the message the one it's in response to gets highlighted (and there's a button to scroll to it if it's off-screen).
I think this Slack feature, like most features, is targeted at helping people using chat sitting in the same room or office together.
I work at a very remote company where with some people I share less than 2 hours of a work day. I want better chat tools centered around making our async communication flow better. Not out-of-room comment threads.
Try Zulip, actually. We use it and it does that exact thing very well.
Any ldap or ad integration?
Yep, see http://zulip.readthedocs.io/en/latest/prod-authentication-me...
It would be quite amusing if it couldn't work with AD, considering Zulip is based on Zephyr which is a very old chat protocol/application heavily dependent on Kerberos.
Just FYI, Zulip uses a similar UI model to Zephyr, but doesn't use the Zephyr protocol internally. (For example, Zephyr doesn't really work when one user is behind a NAT)
(I worked for Zulip, and have contributed to the open-source project)
>The "in-line method" mentioned in this [FastCompany] article about the change is my preferred method: My gripe doesn't stem from rooms being too cluttered, it stems from if there are 4 people talking at once and I'm in two different conversations chains with them, I'd like to explicitly reply to a specific message and carry on the convo. not hide it in a comment thread.
It's fascinating that the preferences for "flat view vs thread view" get revisited in newer software. Fyi, Jeff Atwood blogged about this 10 years ago in 2006.[1]
Thank you for linking that FastCompany article because it emphasizes that Slack's distinguishing rationale was to visually place threads in a different area of the screen. Whether that proves to be the best tradeoff between flat-vs-thread remains to be seen in the marketplace of ideas.
[1] https://blog.codinghorror.com/discussions-flat-or-threaded/