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

Why we’re betting against real-time team messaging

blog.doist.com

Post reply on HN
Print view View original

201–210 of 220 posts

Re: Why we’re betting against real-time team messaging

#201

Post by majewsky »

burntwater wrote: post #178
hedora wrote: post #105

Earlier quoted context omitted.

For a while gmail had this ui "feature" where or string-of-characters would send an email without prompting. I still fear the web UI. I guess emailing out bullet lists was against the implicit use case the gmail UI team had in mind. Stuff like this definitely changes how tools are used.

This exact problem led to my current behavior that I now use in all email apps: I delete/never fill in the "to" fields leaving that for last. Can't accidentally send an email to nowhere...

Entirely unrelated to the Slack discussion, but I wonder if that could be a positive pattern for a mail client: only allowing you to define the recipients when you have written out the full message.

Also, when replying to a long mail thread, showing you the previous list of recipients and requiring you to select those that you want to include in your next mail. Could limit CC sprawl quite a bit.

Re: Why we’re betting against real-time team messaging

#202

Post by majewsky »

amelius wrote: post #185
mhink wrote: post #159

Earlier quoted context omitted.

> I also believe Twitter should have been an RFC, not a startup. I have this reaction to _so many_ online services these days.

It would be fun to actually write the RFCs for those services. Besides, perhaps they could trigger open source and federated alternatives.

"Fun"? I incidentally starting writing a RFC-like spec and it's sooo tedious to define all the little details. (I don't mean that it's not useful. It helps me very much in putting my ideas on a more rigorous foundation, but damn is it tedious.)

Re: Why we’re betting against real-time team messaging

#203

Post by majewsky »

XorNot wrote: post #84
VLM wrote: post #34

Earlier quoted context omitted.

We've left the "social" era and have entered the era of interruptions. All the innovation this decade is in interruptions no longer human-interconnections. My smart watch for example post dates the social era so it has only minimal social features, but its deep in the interruption zone and spams me mercilessly until I block apps and if I block enough apps I may as well have a cheap dumb watch. Another way to look at…

This is a problem even with email at the moment. I spent about 2 hours today trying to get my email filters to a state where my Inbox would only contain email that was (1) generated by a human and (2) specifically addressed to me. Github Enterprise is so far the worst offender - I can't find a non-heuristic way to filter user merge messages (which contain the user name) from actual user comments.

Aren't these sent from noreply@github.enterprise.tld?

In our team, some mails are not delivered because Outlook sometimes accidentally autocompletes `John Doe ` instead of `John Doe `.

Re: Why we’re betting against real-time team messaging

#204

Post by majewsky »

onion2k wrote: post #68
wpietri wrote: post #59

Earlier quoted context omitted.

> That isn't a problem with Slack. That's a problem with the way people are using Slack. The notion that tools exist in some sort of vacuum away from users baffles me. Since Slack's only purpose is talking with other people, I don't how one can even theoretically evaluate it separate from usage. This is a very common thing that happens with Slack. If it were just one team struggling to use it well, you might have a p…

Imagine your company has a mailing list that goes to everyone (it probably does; most organisations do). In a small company it's fine for anyone to send to it but it's quite annoying and unnecessary so the use of it is discouraged by company culture. As the organisation grows there's a point where the email administrator restricts who can send to it because it would be actively damaging to the email infrastructure if…

I saw this at $work some years ago. Someone sent a mail to a weird mailinglist that I'd never seen before, which for some reason had 98,000 subscribers. Cue the "what is this list, please unsubscribe me" replies, which are of course sent to the mailinglist rather than the original poster.

I don't know the innards of Exchange, but from what I've heard, when Exchange receives a mail for a mailinglist, it makes a copy in each recipient's mailbox. That small thread with maybe 30 "please unsubscribe me" replies brought down the entire company mail system for about half a day. (Well, it didn't really bring it down; it was just busy shuffling copies of mails around.)

Re: Why we’re betting against real-time team messaging

#205

Post by majewsky »

nottorp wrote: post #62

All you need is a little self discipline, not a special app. Turn off notifications, check your messages when you're taking a break, do not attempt to chat real time. The only actually useful feature of this app seems to be that it's thread oriented, but you can mitigate that with enough irc (okay, Slack these days) channels as well.

Depends on how the team uses it. When I'm @-mentioned in Slack, it's usually because a system that I maintain is failing or doing weird things, and that's something that I should react to quickly. It's therefore not really an option to turn off notifications (not for @-mentions, at least).

Re: Why we’re betting against real-time team messaging

#206

Post by bahjoite »

beat wrote: post #166
bahjoite wrote: post #119

Earlier quoted context omitted.

Mailing lists are close to perfect; one missing feature from mailing list software is the ability to easily reach back in time to discover threads from before one joined a project. For quick questions and discussions, irc is hard to beat.

Mailing lists are kind of terrible beyond a certain point of complexity. First, they lead to a lot of self-spamming, with internal conversations. Second, if you're not on the thread, you'll never see it. Email depends on enormous duplication of data. And in practice, at large companies, forced expiration is used to control email storage space, in part because of the duplication. So at very minimum, you want something…

> Mailing lists are kind of terrible beyond a certain point of complexity. First, they lead to a lot of self-spamming, with internal conversations.

This isn't a clear argument. What do you mean?

> So at very minimum, you want something threaded like email, but stored in a single location, so storage/duplication/deletion aren't problems

Certainly, the distributed nature of email may pose problems for an organisation which stores emails for a number of its employees. Storage is cheap and backup processes de-duplicate data so using mailing lists shouldn't pose too much difficulty.

Re: Why we’re betting against real-time team messaging

#207

Post by shanwang »

onion2k wrote: post #71
hfauq wrote: post #63

Earlier quoted context omitted.

The online presence indicator is one of the problems created by Slack. Using real-time chat is the actual problem, whether it's Slack or Hipchat, or anything alike. Real-time is great sometime, but I don't think you should use it all the time: - Real-time chat happens quickly — one line at a time — discouraging full, thoughtful conversations. - Topics are all jumbled together in a channel so it’s nearly impossible to…

Real-time chat happens quickly — one line at a time — discouraging full, thoughtful conversations. Slack supports shift+CRLF for line breaks, so users can write epic poems broken up in to hundreds of stanzas if they want to. Using Slack as a one-line-at-a-time chat service is a choice that a user makes. Slack itself doesn't enforce it. Topics are all jumbled together in a channel so it’s nearly impossible to piece to…

I actually think document should be kept/written by a chat/email app.

Most companies have a wiki for document, but how many of them can stay up to date? Discussions happen all the time, and they often require changes to previous documents. Maybe an ideal tool is one can capture team communication, present it in a organised way, and let people edit it later for a more polished view.

Re: Why we’re betting against real-time team messaging

#208

Post by wpietri »

onion2k wrote: post #68
wpietri wrote: post #59

Earlier quoted context omitted.

> That isn't a problem with Slack. That's a problem with the way people are using Slack. The notion that tools exist in some sort of vacuum away from users baffles me. Since Slack's only purpose is talking with other people, I don't how one can even theoretically evaluate it separate from usage. This is a very common thing that happens with Slack. If it were just one team struggling to use it well, you might have a p…

Imagine your company has a mailing list that goes to everyone (it probably does; most organisations do). In a small company it's fine for anyone to send to it but it's quite annoying and unnecessary so the use of it is discouraged by company culture. As the organisation grows there's a point where the email administrator restricts who can send to it because it would be actively damaging to the email infrastructure if…

Sure. And email is circa 50 years old. At this point, given how distributed it is, it's basically impossible to change. It was not designed for the modern environment, so people have compensated with culture.

Slack, however, is new, centrally controlled, relatively easy to change, and frequently updated. So the email analogy doesn't apply at all.

Re: Why we’re betting against real-time team messaging

#209

Post by beat »

bahjoite wrote: post #206
beat wrote: post #166

Earlier quoted context omitted.

Mailing lists are kind of terrible beyond a certain point of complexity. First, they lead to a lot of self-spamming, with internal conversations. Second, if you're not on the thread, you'll never see it. Email depends on enormous duplication of data. And in practice, at large companies, forced expiration is used to control email storage space, in part because of the duplication. So at very minimum, you want something…

> Mailing lists are kind of terrible beyond a certain point of complexity. First, they lead to a lot of self-spamming, with internal conversations. This isn't a clear argument. What do you mean? > So at very minimum, you want something threaded like email, but stored in a single location, so storage/duplication/deletion aren't problems Certainly, the distributed nature of email may pose problems for an organisation w…

It means you'll be getting notifications in your inbox all day while the thread is running, whether you're interested or not. Which gets us in the habit of ignoring them.

The whole point of Doist is to get us away from the interrupt-driven behavior of constant notifications, and the instant gratification of response. Email lists do not solve this problem, unless you turn off your email client entirely.

Re: Why we’re betting against real-time team messaging

#210

Post by beat »

davidw wrote: post #192
beat wrote: post #166

Earlier quoted context omitted.

Mailing lists are kind of terrible beyond a certain point of complexity. First, they lead to a lot of self-spamming, with internal conversations. Second, if you're not on the thread, you'll never see it. Email depends on enormous duplication of data. And in practice, at large companies, forced expiration is used to control email storage space, in part because of the duplication. So at very minimum, you want something…

> Second, if you're not on the thread, you'll never see it. This doesn't make any sense. If you're subscribed to a mailing list, you will see everything sent to it.

Mailing lists are about organization, not content. If I'm on a 20 person team, there will be threads I'm interested in, and threads I'm not interested in. A mailing list doesn't make it easy to ignore the stuff I don't care about.
Post reply on HN