Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I disagree with this article.

This is what was said about GMail when it first came out - you need folders, without folders you can't keep organized, etc.

Turns out indexing and mechanisms to make use of that indexing (labels, advanced sorts, filters) work better than folders.

Persistent chat that can be labelled, indexed, searched and filtered is amazing for work related chats, or any chat that becomes part of a long running context.

We do this where I work, and it works well, mostly - as long as people use the tags.



I don't know about that. There are a few large differences between chat and email, so it's not a great comparison.

1) length -- most emails are significantly longer than any single chat message

2) context -- email threads are saved (and indexed) in the context of their thread.

With chat, you really don't get ether, so it's significantly more difficult. You can never really know what a message is a reply to. Responses can come fast or slow. Individual channels can have multiple conversations happening, if not simultaneously, then at least over time.

> as long as people use the tags

I mean, that's the difficulty with any system... getting people to use it. If your team can be disciplined about the tags, then I'm glad that works for you. I not sure it would work well in many other contexts.

I've tried a few different options over the years, from archiving/indexing IRC chat logs, to bug trackers, to wikis, to email, to Slack, to Notion, etc...

Almost anything can work if you're disciplined. My problem has always been getting the rest of the team on board.


These are great points, though I disagree with all of them as reasons to prefer email over chat.

> 1) length -- most emails are significantly longer than any single chat message

Agreed. The beauty of a chat, rather than an email thread, is that each message contains (or should) a single point. Which means the chat thread is more of a sequence of the following kinds of responses: Yes, and; Yes, but; No, and further; No, but. This makes for a better conversation, and makes it easier to process. How many times have you asked two questions in an email, only to have someone respond to just the last one?

>2) context -- email threads are saved (and indexed) in the context of their thread. >With chat, you really don't get ether, so it's significantly more difficult. You can never really know what a message is a reply to...

This is a matter of implementation, not technical capability. A decent context is achieved through proper use of tags and chronological ordering. Better threading can be achieved through a protocol implementation of a reply-id capability, which most chat systems have (XMPP, Discord, etc.), coupled with GUI presentation of messages in a threaded view.

>...Responses can come fast or slow... True of any asynchronous channel, email or chat.

>Individual channels can have multiple conversations happening, if not simultaneously, then at least over time.

I see this as a feature, not a bug. With tagging a chat message can be part of several different conversations at the same time, even across channels. Which conversation you are presented with depends on which tag you are viewing.

>I mean, that's the difficulty with any system... getting people to use it. If your team can be disciplined about the tags, then I'm glad that works for you. I not sure it would work well in many other contexts.

In my experience, this is often the biggest hurdle in implementing any revolutionary system (as opposed to evolutionary) that makes a big change in how people do things. For messaging, there are systems with a reminder feature similar to most email client's behavior when there's no subject. For instance, "This message has no tags. Messages are required to have at least one tag, and should have between 2 and 7".

You need management to force the issue though. An approach I've used in the past is to find a competitor or two using the technology, and use business/financial FOMO as a motivator.

Also, if you do a typo in an email..it's there forever. A typo in a chat can be fixed in many systems.

In a desire to be fair, I will add two reasons to use email:

1) If you are doing CYA. Email can't be changed, and is routed through a number of servers, possibly leaving log fingerprints. Email also has bcc. Anything that is important you can bcc to a second friendly party to prove you sent it, or to a personal email account (do this with trade secrets, or heaven forbid - classified - and you should get what you deserve, and I don't mean in a good way). If you want a paper trail, don't use chat.

2) If you are sending a document. Most businesses have virus scanners built into their email server software. A document is typically sent, retrieved, and saved somewhere. Though, if a document will be referenced often by many, neither chat nor email are best. Use a wiki, or something similar.


Exactly, I completely reject the premise of this article. In the last hour I searched the "alerts" channel to see how many times our database had high CPU in the last year.

I'm not one to defend slack, but there's nothing inherently temporary about slack. And searchability > manual categorization.


That doesn't seem enough to reject the premise of the article, which explicitly calls out that chats are great for both "Low-stakes status updates" and "Swarming around red alerts or outages", a high CPU alert that was just a notification is the former, a high CPU alert that people discussed and fixed is the latter.

Also, your "database", singular? Was the answer something like 10 times? Would that scale?


"as long as people use the tags"

That's the crucial point here.

UIs need to help users to find the appropriate tags, often tagging is either included implicitly, which leads to forgetting or clunky, which leads to aversion.


The sheer volume of information that Chat holds makes it hard to search. The noise to signal ratio is higher than on channels with lower throughout (e.g. documentation products). Chat doesn't let you send one message and craft it over time, like a mission statement, proposal, or architecture guide. It has a fundamentally different character.


And some chats are worse than others. Teams does this so poorly it brings my battlestation to its knees trying to do simple text search.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: