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

71–80 of 220 posts

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

#71

Post by onion2k »

hfauq wrote: post #63
onion2k wrote: post #11

A small, but impactful design choice we made in creating Twist was to leave out the online presence indicator. I imagine you could address this in Slack by just having everyone set themselves to 'Away' by default. One of the things that I've found useful in Slack is turning off the "Someone is typing" message (the option is in the Display Options). I used to wait for someone to post if I knew a message was coming. No…

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 together the full conversation.

Only if users interrupt the current conversation with something else. Again, this is a cultural choice that users make. It's not a Slack thing, or even a chat thing. Also, Slack does support threaded conversations (albeit with a pretty horrible UI).

Important team knowledge — like what decision did we make and why? — gets buried and lost within hours (even with powerful search).

I totally agree. Slack is not the right place for documenting important stuff. Nor is a different chat app, or email. Important knowledge should be put in a knowledge management app (eg a repo wiki for code, or a Word doc for business related things).

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

#72

Post by nchammas »

This post reminds me of a similar one by the CEO of Basecamp giving his take on the problems with group chat and their solution to those problems.

https://m.signalvnoise.com/is-group-chat-making-you-sweat-74...

> Group chat is like being in an all-day meeting with random participants and no agenda.

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

#73

Post by dsr_ »

amelius wrote: post #17
onion2k wrote: post #11

A small, but impactful design choice we made in creating Twist was to leave out the online presence indicator. I imagine you could address this in Slack by just having everyone set themselves to 'Away' by default. One of the things that I've found useful in Slack is turning off the "Someone is typing" message (the option is in the Display Options). I used to wait for someone to post if I knew a message was coming. No…

It sounds like you kind of ended up with e-mail :)

Usenet news.

1. You enter groups devoted to large topics (like "all company" or "software development" or maybe "Smith Project")

2. You see conversations delimited by subject lines, completely threaded, with full history.

3. You normally reply to a message with another message, quoting or not, and your message is threaded in.

4. The tools are good for showing you what you haven't read yet.

5. You can ignore a topic forever.

6. You can have filter highlight topics where your name or email address or a keyword is mentioned.

7. You can seamlessly fall back to email for private conversations.

8. There's an archive that goes back to the limit of storage space.

9. Usenet is, of course, easy to distribute and federate.

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

#74

Post by sergiosgc »

I don't think the fundamental problem is one of sync vs async communication. Of course synchronous communication is a flow killer, and of course having it as a team-wide or company-wide means of communication aggravates its problems. The async nature just makes it worse, as it has more bandwidth, and consumes more brain bandwidth as a result of more content than email and wider distribution than email.

The problem lies between unstructured and structured information. The problem is one of process vs flying by the seat of your pants. Ideally, you want processes for every repeatable action, and more flexible means of communication for new events that need to be handled quickly by those empowered to solve them.

However, every repeatable process starts as an one-off event: Customer requests for the same actions pile up until the moment you realize your app needs a new feature; Faults occur and get solved up until you realize you need to engineer a solution that prevents or automatically fixes them; Internal processes get lost and hang until you decide to redefine the internal workflow.

What is missing is a simple way of moving unstructured communication (sync and async), onto structured communication. Chats should end up as feature requests, bug reports, documentation or some other permanent medium that fits into the process.

If the unstructured->structured bridge is solved, you don't have to monitor chats (or mailing lists, or forums). If they result in something meaningful, they will appear in the structured, process-oriented flow. Monitor that, and get involved in chats where you are directly mentioned. (and skip all gif chats, really)

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

#75

Post by Eridrus »

csydas wrote: post #39
onion2k wrote: post #11

A small, but impactful design choice we made in creating Twist was to leave out the online presence indicator. I imagine you could address this in Slack by just having everyone set themselves to 'Away' by default. One of the things that I've found useful in Slack is turning off the "Someone is typing" message (the option is in the Display Options). I used to wait for someone to post if I knew a message was coming. No…

I would agree that culture is a major factor - we briefly implemented Slack a few years back at a company before I left, and I watched it drive our Senior Programmer nuts, as we didn't really have good solid rules or behavioral standards for Slack. I'm not talking about a tome of laws and regulations, but just a few simple things like "Don't spam chats with non-work related items", "Don't spam looking to get someone'…

I think giphy integration is a huge mistake for Slack. I used Flowdock at my last job and it didn't really have the problems people tend to talk about wrt Slack. We also had separate channels for separate teams, so it wasn't one big free for all.

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

#76

Post by dood »

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…

It is true that Slack allows multi-line posts and discrete conversations, but both go totally against the grain of the system design.

Expecting people to use Slack in a way it wasn't designed for can only result in failure or constant friction.

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

#77

Post by cntlzw »

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.

Exactly. You just need to establish some ground rules on how things are to be done. Most tools are just tools. You need to define some workflow to go with it, otherwise you don't get any benefit or upset people.

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

#78

Post by tvaughan »

josephg wrote: post #32
akhilcacharya wrote: post #6

Earlier quoted context omitted.

I mean, isn't Dropbox just prettier rsync?

And Slack is a modern version of IRC :) It keep being surprised by how much a fresh coat of CSS and a mobile app can reinvigorate these old ideas. Who knew how important adding gifs and emoticons would be?

https://grove.io/

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

#80

Post by s_kilk »

wpietri wrote: post #59
onion2k wrote: post #15

Earlier quoted context omitted.

And heaven forbid somebody typed "Good morning, @channel" (which happened 20 times per morning per timezone), because then you'd get the dreaded Red Exclamation Mark in the tab. That isn't a problem with Slack. That's a problem with the way people are using Slack. If the only workable fix is to use a different tool you have a far bigger problem at your company. I can't fathom how anybody would have been able to work…

> 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…

> The notion that tools exist in some sort of vacuum away from users baffles me

This x1000

Software is developed and used in a social context. We can't disavow responsibility for the effects our Software cause.

Post reply on HN