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. Now I can drop in and out of a channel more easily. Similarly, I've muted almost all the channels I'm in so now I only need to check if someone notifies me.
The point I'm making is that Slack doesn't necessarily work the way you want right away, and that you might need address a few cultural problems with the way your team uses it. You need to think about how your team communicates, consider why people do annoying things in it, and come up with solutions that work. At the most extreme that might be writing a competitor product but for most companies there just needs to be a little more tolerance of people not answering immediately and a little consideration that gifs can be unhelpful.
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 piece together the full conversation.
- Important team knowledge — like what decision did we make and why? — gets buried and lost within hours (even with powerful search).
- The real-time nature of communication excludes anyone who’s not there in the moment it takes place.
- Constant notifications eat into your time and attention.
- Even if you’ve turned off notifications, the fear of missing out on something important keeps pulling you back into the app.
- It slowly creates a culture that prioritizes being available over doing good work.
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).
> Using Slack as a one-line-at-a-time chat service is a choice that a user makes. Slack itself doesn't enforce it.
Thats like saying you can drive your car with your feet, the car doesn't enforce driving by hands. The point of this post is saying that slack has these shortcoming by the nature of its design. You can make as many arguments as you want defending it, but everything has a design that influences usage.
Thats like saying you can drive your car with your feet, the car doesn't enforce driving by hands.
That's a slightly odd analogy, but let's go with it. You're right that you can drive a car in ways that are dangerous, and the car doesn't enforce safe driving. The law is what enforces the way you drive (by punishing you for driving dangerously). This is exactly the same as company rules to ensure Slack is used properly. So, yeah, I guess it works pretty well, and people who use Slack badly are "foot-drivers".
Pretty sure the GP doesn't care about the law in the analogy; the design of the car itself impedes your ability to drive with your feet.
In the same way, slack is frictionless to post one-liners; you have to go out of your way to post a multi-liner (and I personally have the constant worry I'll miss the shift and post half-finished in such systems).
It doesn't matter if the law (company) says to drive by hands; you have to be really intent on driving with your feet to get into a car and do such a clearly unnatural thing. It's difficult to imagine someone new getting in and thinking this must be the correct position, because the car does not support it naturally. It can be done, but only while dealing with friction.
Then compare slack to a bbs forum, where people naturally post paragraphs. Not coincidentally, the act of posting has more friction; CLRF is a newline, posting is a button off at the bottom of the page. To get a better ratio of value (writing) to friction, you'll simply have to write more and post less.
The law (company) can enforce unnatural behavior onto its populace, but when the law is unclear or unstated (or ignored) on the particular matter, the natural activity depends on the environment.
And slack is very clearly predisposed to a particular kind of posting.
Not just the system design, but also the culture. I know a few people who post coherent, properly punctuated and capitalized sentences and paragraphs here on HN, but they write on Slack like this:
What you describe is the most natural, effortless way to use Slack. Conversely the design makes it very cumbersome to compose thoughtful, well-formatted responses. And the more people use the former style, the less value the latter has. So users tend toward spewing out crap rather than having considered discussion, because Slack's system design strongly encourages it.
It takes so much cultural pressure, moaning and nagging to use Slack in a high signal-to-noise manner that I'm quite bearish on it's long-term prospects, and applaud OP's effort at building a system designed more for collaboration than shitposting.
How are shift+enter newlines "totally against the grain of the system design"? Most every chat system I'm aware of supports this and displays it in a sane way. If people are misusing the system, training/instruction is in order.
It may seem like a little thing, but you have to be very careful while typing not to accidentally press Enter. I've found this to be surprisingly difficult, and it makes typing a lot more stressful.
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.
In the case of Gmail (and most email systems really) I always start out by putting my own address in the To: field. That way if I accidentally send it will just come back to me. It can also be useful because I can first send the email to myself to double check the way it will look on the receiving end before sending it to the actual recipient.
The trick I use if I'm writing anything more than one paragraph is to write it first in my #mike personal channel (easy to get to with Ctrl+K or Cmd+K), and then copy and paste it to the channel it's intended for.
This way I don't have to worry about hitting Enter at the wrong time. I can also preview the message so I see exactly how it will be formatted, and no one has to see the "mike is typing" messages while I edit.
I also went to the extreme of creating a private Slack team just for myself. I was using the personal channel trick and found that if I included an image in my talking-to-myself message, and then pasted it to another channel, it didn't automatically display the image in that channel. I guess Slack figured the image had already been displayed somewhere within the team even though it wasn't in a public or private channel. I have a feeling this has been fixed by now.
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.
If people are making big, irreversible decisions in real-time on slack without a lot of deliberation, that does sound like a problem, but it hardly seems like slack's fault. The same thing could happen over email via several quick replies, or just in person with whoever happens to be nearby and not wearing headphones.
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's attention", etc. The Senior in question was an older guy who had a lot on his plate and and a bit of a short fuse. It absolutely ended up driving him nuts as now instead of relatively quiet and ignorable chat messages, he was getting spammed and pinged by absolutely everyone at once, and those in the office with less on their plate definitely treated Slack like their own IRC channel for shitposting.
Poor support from our management in general, and a poor delineation between private channels and public channels resulted in a lot of private rants being exposed publicly (not just from the Senior), and the end result was Slack was shelved for the time being and the Senior Programmer left the company.
My new place of employment utilized a multi-tiered approach, using Skype for quicker questions (with rooms dedicated to specific topics or aspects of the work), and anything requiring more than a sentence or two of background being regulated to an internal message board system. Our management is quick to shut down too much spam, and everyone in general is taught about the expected etiquete of the chat.
Without such precautions, I think it's too easy to fall into the more casual "shitposting" that is common for message boards and the chatrooms of old. Workplace chats are meant for very narrow and specific purposes, and it needs to be enforced that these are not the places to be spamming the latest gif you found on reddit/imgur.
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.
Everything old is new again. (And Usenet is even still there.)
I'm still convinced that Usenet gets ignored precisely because it is federated and mature - it is harder to extract nickels from than a centralized service; user-surveillance and other ad-related choke points are fragmented, it works already, there are already robust end-user filters.
(I also believe Twitter should have been an RFC, not a startup.)
For anyone who wants to build similar stuff for internal use - NNTP is probably not going to be the right choice unless you have a large number of sites. For a startup, IMAP has everything you need built-in for shared, threaded group messaging that looks a fair-bit like usenet (from the client's perspective). If you don't have strong ideas about UI or workflow, you can use an MTA to read and respond, and you're done. If you want your own UI, there are a huge number of IMAP libraries out there for just about any language you want to use.
"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.)
I'm a non-native speaker. I'm guessing you're saying the adjective is dated and reading it again it does sound like that. Still, i was trying to say 'faster than the usual fast'
Usenet was not historically real-time because of several things:
1. There were a lot of servers.
2. The servers were not arranged in an optimal network.
3. The network was full of cross links, many of which made no topological sense.
4. Not every server carried all newsgroups.
5. There were a lot of users, who read a lot more than they write.
6. Binary messages (when carried) grew to huge sizes (for the time).
7. Network links were very slow by today's standards.
8. Disks were slow, small and expensive by today's standards.
9. Every ISP felt it had to provide free Usenet service, but few of them did it well.
With modern hardware, Usenet could be as close to realtime as you expect email to be -- dominated by people's attention and writing speed. And carried over TLS, of course.
There are internal message board systems in Microsoft shops (i.e. Sitrion on SharePoint) that struggle to achieve 2,3,4,5,6,7,9. Despite beefy servers and huge $$$, still slow and lame.
I would like to see a meaningful discussion of the tipping points between various forms of communication.
ie: Phone call when you need immediate, high-bandwith dialog; IM when want to chat, but don't need instant responses; email when you want persistent communications, etc
Those are very brief, single faceted views, and there are a lot more factors.
> 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. Now I can drop in and out of a channel more easily.
I've also noticed that being in the dark about some things regarding real-time communication makes me happier. E.g. I disabled WhatsApp's "read" and "last online" indicators not because I don't want others to see mine but because they are useless information that only made me wonder about other peoples intentions.
When somebody has read the message and didn't respond, it doesn't mean that they never will but that they were otherwise busy. Just knowing about that didn't keep me from wondering, only turning it completely off did. If I was able to turn off the "typing..." and "online" status, I would, too.
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. Now I can drop in and out of a channel more easily. Similarly, I've muted almost all the channels I'm in so now I only need to check if someone notifies me.
The point I'm making is that Slack doesn't necessarily work the way you want right away, and that you might need address a few cultural problems with the way your team uses it. You need to think about how your team communicates, consider why people do annoying things in it, and come up with solutions that work. At the most extreme that might be writing a competitor product but for most companies there just needs to be a little more tolerance of people not answering immediately and a little consideration that gifs can be unhelpful.