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

If it will matter after today, don't talk about it in a chat room

critter.blog

Post reply on HN
Print view View original

101–110 of 329 posts

Re: If it will matter after today, don't talk about it in a chat room

#101

Post by hn_asker »

mumblemumble wrote: post #46
legerdemain wrote: post #25

The problem with "trying it with my team for one sprint" is that I now need to have a long conversation with legal. How will the service provider handle the content (discussions, screenshots, code snippets) that my team will upload? Do our current customer contracts contain any clauses that complicate the use of external discussion sites? In the unlikely event that the service offers the option to host it locally --…

There is really only one fundamental problem with email: its mechanism for managing who takes part in the conversation is all wrong for team communication. The symptoms of this problem are myriad: reply-all storms, cya-by-cc, replying to a 5 month old email rather than starting a new thread, fyi forwards, etc. Which isn't to say that all the advantages you list for email are not true. They are. It's just that most pe…

I hate it when I'm emailing someone with a deliberately long response and by the time I send, the thread has already gone on and I have to re-merge it.

Re: If it will matter after today, don't talk about it in a chat room

#102

Post by Sodman »

andrenotgiant wrote: post #37

It sounds like the author was mostly thinking about INTERNAL discussion, but I think the real tragedy is in using chat like Slack for your public customer community forum. Think of all the knowledge and employee-time locked away in the scrollback of a chat based community forum. Better to have chat for informal community discussion, but when someone asks a question that others in your community might find useful in t…

My experience so far with companies that operate in this manner, has been something like:

1) Community member asks question.

2A) Answer is already in documentation, which can be easily linked to.

Or

2B) Can be answered in-line, with an action item to add clarification/more details to the docs.

This feels like a pretty scalable solution for the most part. If there are still recurring questions you might want to look at the discoverability/layout of your docs, but usually I've found that other community members start linking each other to docs if the same question comes up again and again.

Re: If it will matter after today, don't talk about it in a chat room

#103

Post by nobody9999 »

jcrawfordor wrote: post #85
nobody9999 wrote: post #80

Earlier quoted context omitted.

>I'm just a dumb machine operator that uses Outlook at work, Fastmail for myself, and Gmail because I'm an idiot too, and really can't tell the difference. Install Thunderbird[0] and use it for a week. You'll be able to tell the difference very quickly. [0] https://www.thunderbird.net

I'm a Thunderbird user, but I don't really think that there's a clear winner in that comparison. Outlook has features that Thunderbird has been missing for over a decade, like reliable send-in-background (and other database operations in background unlike Thunderbird that likes to interrupt you to ask permission) and a far more mature calendar product.

>I'm a Thunderbird user, but I don't really think that there's a clear winner in that comparison. Outlook has features that Thunderbird has been missing for over a decade, like reliable send-in-background (and other database operations in background unlike Thunderbird that likes to interrupt you to ask permission) and a far more mature calendar product.

A fair point. As someone who has used both Outlook (professionally) and Thunderbird (personally) for decades (IIRC, the oldest message in my Thunderbird email store is from 1996), calendaring in Thunderbird isn't as robust as in Outlook and some of the other weaknesses you mention are absolutely valid.

However, I'd say that many of the advantages of Outlook that you mention are more related to better integration of Outlook into Exchange back ends than to the Outlook client.

If Exchange had better IMAP support and appropriate plugins for Thunderbird, Thunderbird would be vastly superior to Outlook in most respects.

As it is, Thunderbird is already vastly superior to any web-based MUA[0], including OWA[1].

[0] https://en.wikipedia.org/wiki/Email_client

[1] https://en.wikipedia.org/wiki/Outlook_on_the_web

Edit: Clarified Outlook/Exchange integration vs. Outlook as client.

Re: If it will matter after today, don't talk about it in a chat room

#104

Post by indymike »

This argument has been going on for decades. Chat vs. threaded discussion vs. email. The best one for me is where the people I need to communicate are listening. The hard part is getting everyone to listen in the same place. It doesn't matter how good the UX is, if you need the CEO in the chat and she only does email, then email it is.

Re: If it will matter after today, don't talk about it in a chat room

#105

Post by Const-me »

emidln wrote: post #27
legerdemain wrote: post #25

The problem with "trying it with my team for one sprint" is that I now need to have a long conversation with legal. How will the service provider handle the content (discussions, screenshots, code snippets) that my team will upload? Do our current customer contracts contain any clauses that complicate the use of external discussion sites? In the unlikely event that the service offers the option to host it locally --…

Many organizations seem to use Outlook/Exchange and configure Exchange to make it difficult to use other mail clients (not enabling imap, not enabling caldav support so that a separate calendar and email client need to be used unless you use exchange, etc). Outlook is truly awful as a mail client and it would make one want to use anything else.

I've been using Outlook for 20 years or so, and I generally like it. Lots of features, some of them are borderline unique. For instance, I wonder which e-mail clients allow to create complicated rules that are then running on the mail server as opposed to that client?

The necessary conditions are (1) one needs to learn it. Too many features are making UX non-intuitive. (2) fast connection to e-mail server (3) ms exchange on the server, some features only work there.

Re: If it will matter after today, don't talk about it in a chat room

#106

Post by ogre_codes »

GekkePrutser wrote: post #72
jrockway wrote: post #51

I have always thought that Slack is designed to make information go away, and that's why people like it. Email never goes away unless you archive the thread. If you have a bunch of things that are going on, you open your inbox and realize just how behind you are, every time you open it. Slack, conversely, scrolls up and always looks the same. If you miss something, the world moved on without your input, and you feel…

Well, a real paid slack instance doesn't go away. All the public free slacks do.. The whole fact that Slack charges a lot for the privilege of keeping history beyond a couple of months, proves that it's worth a lot to many people.

Yes, but as gmail has illustrated, that just shifts the problem. Where before your problem was "It got deleted". Now the problem is search pulls up too many things.

Slack seems to be even worse because unlike email, you don't really have subjects or thread beginnings, just continual flow of chatter.

Re: If it will matter after today, don't talk about it in a chat room

#107

Post by powersnail »

dumbfounder wrote: post #29
legerdemain wrote: post #25

The problem with "trying it with my team for one sprint" is that I now need to have a long conversation with legal. How will the service provider handle the content (discussions, screenshots, code snippets) that my team will upload? Do our current customer contracts contain any clauses that complicate the use of external discussion sites? In the unlikely event that the service offers the option to host it locally --…

Those emails are only available to the users participating in them, and in some places are automatically deleted after a certain amount of time. The point of TFA is knowledge capture, and email isn't transparent enough for sharing knowledge.

This gives me an idea. What about setting up an archiving script?

After a archive-worthy discussion in email, you forward the thread to "archivebot@my-company-domain.com". The script will parse the email chain and generate a static web page hosted on a local server.

Re: If it will matter after today, don't talk about it in a chat room

#108

Post by fennecfoxen »

fiddlerwoaroof wrote: post #94
mumblemumble wrote: post #88

Earlier quoted context omitted.

Not really, because it still doesn't give people sufficiently fine-grained control over demands on their attention. I think the ideal is the approach you get with discussion forums: Create a set of boards organized around topics, and place named, threaded conversations within those boards. People can join a board, in which case they will be able to get a list of new conversations related to that board's topic. They c…

What’s the difference between that sort of topics and news groups or mailing lists (with archives)? If I want information on something, subscribe; if I don’t want information, unsubscribe: I can always follow/search the archive (or read digests)

The archive on NNTP is a first-class artifact that you can interact with in your newsreader via NNTP. You can do things like reply to old threads.

The archive on a mailing list is a second-class artifact, typically hosted via HTTP, and usually people don't care about the quality of the archive's UX.

The structural organization on NNTP is also a first-class artifact that everyone can refer to. A mailing list will go straight into everyone's inbox, with all their other mail, until they filter it away.

Re: If it will matter after today, don't talk about it in a chat room

#110

Post by ketzo »

jrockway wrote: post #51

I have always thought that Slack is designed to make information go away, and that's why people like it. Email never goes away unless you archive the thread. If you have a bunch of things that are going on, you open your inbox and realize just how behind you are, every time you open it. Slack, conversely, scrolls up and always looks the same. If you miss something, the world moved on without your input, and you feel…

From my experience, the mark of a well-run Slack is the ability to find old, valuable information. You're right that it's not always easy, but you can get a LOT further with 1) well-defined channels 2) good use of pinning 3) good use of "saving" messages for yourself.

It helps that Slack's search is actually pretty good imo, and usually quite fast.

But yeah -- it can't be your only tool. If you don't have a better system for long-form documentation, you're gonna lose a lot of important stuff.

Post reply on HN