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?
I'd say history access/logging by default, easy sign-up, easy management/configuration are all way more important reasons. Someone very likely could have gotten all that working as a good product based on IRC, but they didn't. (I use IRC a lot more than Slack, but my requirements are not the same as those of a company adopting Slack)
Jokes aside, the article did hit the nail on the head in its critique of realtime comms. That said, there was always a subset of any team that seemed to have cold feet / anxiety / or other resistance to writing the longer-form messages of newsgroups.
I think if I had to pick between shallow, but broadly used comms, and slow but heterogeneously used comms, I'd still pick the latter.
I can't believe that they even wrote a new app when they could just have installed mailman, or any other mailing list server, or even a news server.
If I were to create a company I would create mailing lists for discussion and a wiki for consolidation of knowledge. In my humble opinion, there is no need for new fancy apps. The tools are there.
What does the new app they created provide that cannot be done with the tools I mentionned?
I feel old. I'm 36 years old and I see too many articles of people discovering stuff we discussed at length in the 90s. This IRC vs Usenet discussion is an old one.
This makes a good point that Slack can sometimes just be a better hamster wheel for time wasting. I have seen it work well as an emergency channel, where dev's could quickly share info if a live app was having a problem. But at the same place, the most lively channel was an exchange of GIFs.
I like it. I've been thinking for a while that old-school forums are actually fundamentally superior to chatrooms for sharing important information and having in depth discussions.
In my opinion the chat model is simply bad for effectively distributing useful information because it disappears in the noise.
Perhaps what's needed is a combination of the forum-style threaded conversation model for information sharing and work conversations and a chat room which is explicitly for the water-cooler stuff, so that people don't have to be always-on (and constantly interrupted). It should be safe to turn off when you need to focus.
I disagree. It takes all kinds. There isn't one right way for people who work together to communicate. Real time messaging solves a specific set of needs but is not the end-all be-all. Threaded more thoughtful forum style communication is important too, it's much better than email for that sort of thing. Email is also important for what it's best at.
Work communication isn't a technology problem as much as it's a human problem.
Just off the top of my head here are a few types of communication that need to happen at work. In modern work we can assume not everyone can be in the same physical space.
* solve an important problem right now
* find consensus on a complicated problem where opinions vary and emotions run strong
* info everyone needs to be aware of now
* info only a few people need to be aware of now
* info that might be of use within some time horizon for few or all
* relationship/trust building (small talk, gossip) don't dismiss the value of this one
I don't think I've really heard much about that product since the announcement. Is it good? And are accounts tied to Facebook proper? That would turn me off completely.
I was cynical about it to begin with, when it was just 'Facebook at Work' but I do believe it addresses a lot of the issues brought up in the blog post and the Workplace team are executing very well.
Accounts are completely separate from Facebook, no crossover at all.
I don't think it's a Slack killer, as they both solve different problems in different ways, and Workplace is very much a 'big co, top down' approach.
I do think other existing collaboration tools have a lot to be worried about between Slack & Workplace though.
Last stat I heard was there is over 14k companies using it.
Sounds pretty decent! Would be interested in trying it if my employer didn't roll its own team chat for this purpose.
Maybe Slack should be worried too. They may have a tough road ahead growing into the valuation between Facebook Workplace, Microsoft Teams, Atlassian HipChat and Amazon Chime.
> Accounts are completely separate from Facebook, no crossover at all.
This was the claim that was made when we tried out FB@W, but shortly after I created my work account (I don't have a personal account) my wife started getting friend suggestions for coworkers of mine she's never met. I never even used my @work account for looking at her FB account, wasn't friended to her, etc.
I think it was either a) harder to undo all the creepiness, or b) they didn't want to.
I used to think that too and even began to write something like that. But what happens if something important accidentally is discussed on the chat? Right, someone has to move it to the sticky "forum" part of the app. That is complicated.
I'm sure it's not dead simple, but that doesn't mean it's worse by any stretch.
On further thought I wonder how much of the problem I have with slack and similar services (of which I actually tangentially happen to work on one) is more of a problem with process and expectations than anything else.
1. You are expected to be on chat, otherwise you suffer the appearance of not working - counter-productive since you are now subject to distracting notifications. If do-not-disturb settings and turning off notifications wasn't frowned upon this might be less of an issue.
2. Important information should be distributed through a more persistent second channel, email or a web-viewable email-list may actually be suitable.
Most open source projects still use mailing lists, which are even better than forums in that everyone can read and write emails in whatever client they prefer.
And yes, it's far better than chat for serious discussions, with a global group of people. You don't want to exclude the Americans from important decisions when everyone in Europe is awake and on the chat in the morning, and vice versa.
I think both systems have their places - if I have a quick question, chat is usually better. For longer more serious discussions, perhaps with code included, email wins.
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.
> 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.
I must be missing something, I've always found mailing list UIs frustrating to navigate and explore. Does anyone maybe have a primer on how to get the most out mailing lists for someone not already intricately familiar with them?
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 threaded like email, but stored in a single location, so storage/duplication/deletion aren't problems, and indexed searching is available. This also allows things like tagging someone into a thread after it already started.
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.
> 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.
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.
I think the same thing. I had a hell of a time trying to move a company from Slack to Discourse though. People really love the UI/UX of Slack, even more than they hate the information overload.
I worked at a Slack shop for several years, and share the author's opinion.
I can't think of any five minute period during my entire tenure where the Slack tab didn't have a little red circle telling me that I absolutely needed to check it right this second. There was no way to filter notifications beyond "Everything", so that little bubble would go up every time anybody in the company pressed a key. 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.
I can't fathom how anybody would have been able to work if they had gone as far as allowing notifications to be turned on and make noises at them every time Slack thought something Important Enough To Interrupt You had happened.
More granular controls really would fix this problem. For instance, per-channel settings to have the channel highlighted in the sidebar when it has new messages, but without badging the tab/dock. That way you could reserve the badges for the channels you really need to monitor closely, but not have to check every single other channel explicitly to see if there are new messages.
Man, that would be amazing. It would be sweet if there was a third party slack notifier that could do that kind of thing. Basically you just run the notifier and quit the main slack app, until the notifier tells you to pull it up. Then you interact with it, and when you're done, quit it again.
Take a look at the Channel List under Preferences -> Advanced to only show unreads, then combine that with individually muted channels. That's how I have most channels set up so I can passively aware of activity with badges.
The problem is that instead of having to check every single one of my dozens of muted channels once or twice a day, I'd like them to be highlighted in the sidebar (but not badged!) when unread. Plus it'd be nice to still get notifications of mentions and highlight words in said channels.
By hiding the ones with unused messages you implicitly tell which ones have new messages because those are the only ones that are visible. It works quite well and enabled me to passively track dozens of channels without being overwhelmed.
As to mentions and highlight words, I don't think there's a solution for that for muted channels. When I developed this technique I would have liked targetted mentions, but not @here or @channel, which, at the time was indistinguishable. However Slack added a per-channel option to Ignore notifications for @channel & @here, which means I might try the above technique without muting the channel.
Play around with it, you might find the settings can be combined in an optimal way once you understand how they all interact.
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 if they had gone as far as allowing notifications to be turned on and make noises at them every time Slack thought something Important Enough To Interrupt You had happened.
All the notifications and noises can be switched off, and the @channel and @here notifications can be ignored on a per channel basis.
All the notifications and noises can be switched off, and the @channel and @here notifications can be ignored on a per channel basis.
Sounds like a feature that was added in the last 18 months since I last used it. At the time, your options were "every notification about everything, ever" or "no 'notifications' ever, but we'll still helpfully flash the favicon at you all day".
Glad to see there is at least a tiny drip of sanity making its way into the product.
> 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 point. But past a certain size, I've only ever seen Slacks that a) have a problem with @channel, or b) have a carefully developed and enforced culture of controlling use of @channel.
I think the sophisticated version of this argument is "only experts should use use complex/difficult/dangerous tools". Which is a reasonable argument when talking about, say, wiring up detonators. But Slack's purpose is to connect everybody in a company. Suggesting that Slack is only for experts is to limit its market to a very small segment.
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 too many people used it, and it'd annoy a lot of people.
Very few people abandon email because their organisation has a mailing list.
Slack's @channel is exactly the same thing albeit on a smaller scale. If it gets too distracting just tell people not to use it so much.
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.)
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.
Your company has hammers and screw drivers as your tools. If your employees only know how to use hammers, they are going to hammer screws. If your team only knows how to use screw drivers, they will shrug at nails. Hence, the tool is not always at fault for end user error.
Learning how and when it is appropriate to use the tools at hand is important.
The thing about software is that it enables us to do things we do well faster and more consistently by a large factor, it also causes the things we don't do well to multiply their damage.
My previous workplace everyone had tight deadlines and goals to meet, they were pressured both internally and externally to act in their best interest, this means that everyone believes their problem is top priority even when it's not a priority at all, and Slack makes communication a billion times faster so they bother whoever they can on Slack.
This usually means one of two things, either going to someone directly or blasting everyone on the channels that contain the entire company, this became the default for us and it was hell, at some point people would notify the entire channel because they couldn't find their mug.
IMO what Slack does, in this case, is expose much bigger issues within the structure of the company, these can't be fixed by switching chat apps.
My current company the communication channels and prioritization are very clear, Slack is not a problem, it is a helping tool.
I don't think anyone said that Slack is only for experts, but a training session or two wouldn't be remiss. Here's how you handle notification preferences, slash commands, and such. Especially for wide deployments among people of varying tech literacy.
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 it is we no longer have 100 people shallowly liking us, we now focus on 100 apps shallowly claiming our attention is vital because we are important and we must be interrupted now.
Some of this is probably cultural backlash against automation and bureaucracy and general economic decline. If more people than ever are in fact not useful or important at all, then a communication style focused primarily around telling people they're important, is going to be very popular.
Under that analysis Slack is a post-social communications media, and it constantly rewarding you with endless micro doses of "your attention is valuable" is not a bug, its the whole philosophy of its existence as an app. You can see why curmudgeons see Slack as something negative, like the intrusion of participation trophy culture, because thats pretty much what it is.
The purpose of Slack is to constantly interrupt you with a narrative that you're important. There are incidental side effects that make it semi-useful. Companies spend a lot of money on "make employees feel special" and Slack is merely a modern example of the genre.
This philosophical analysis of Slack is probably extendible past Slack into startups. Don't try to market something as interconnectedness, not in 2017. Try to sell something that symbolically, or whatever, tells people they're important.
> My smart watch ... spams me mercilessly until I block apps and if I block enough apps I may as well have a cheap dumb watch.
Definitely block the spammy apps. It makes a huge different to the smartwatch experience if it's only buzzing for things that really are urgent. Once you tune the notifications, it's actually calming - not only because you're not being interrupted as often, but also because you're not constantly thinking "is there something that needs my attention". If there is, the watch will let you know.
To me, that doesn't make much sense; the whole point of a smartwatch seems to be making the reading of notifications more efficient and unobtrusive. If you disable all except the rare urgent ones, what's the point of the smartwatch?
Notifications are inherently intrusive. You have to pare it down to the set of notifications you care about most so that you aren't constantly interrupted. I made the mistake, recently, of letting the News app on iOS notify me, no sound but near constant visual noise when some big news item comes up. All I care about is: chats and calls from girlfriend, family, friends (in that order), a couple chess games, calendar/todo notifications to keep me on schedule (particularly on busy days). Everything else, I can check at my leisure. If I had a smartwatch, it'd be convenient to have those on my wrist. But I certainly wouldn't want all those news notifications there, though I may still want them on my iPhone or iPad.
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 <noreply@github.enterprise.tld>` instead of `John Doe <john.doe@megacorp.tld>`.
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.
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.
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.
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 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.
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).
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.
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.
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.
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.
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.
> 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.
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.
> 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.
> But in reality, even I couldn’t keep track of all the conversations that were happening at the company.
Nor should you, really. Imagine trying to do that in an office-based organization! Slack, to me, is a bit like our digital office space.
You can also use highlight words to ensure you don't miss any discussion on topics you're particularly interested in. We have a guy who worked a lot with our billing, and he is magically always present whenever anyone says "refund".
Just went through Startup School that uses Mattermost, which seems to be a Slack clone (not sure since I never used Slack).
It didn't seem to work well. Since all members of all groups were from all over the world and rarely shared a timezone, no conversation could really take place in real time.
And since there are no threads or topics or anything, it's almost impossible to go back to something that was said a while ago.
I think a subreddit would have worked much better.
My company is looking at using Mattermost, but I have the same qualms, since it honestly won't be much better (if not worse) than using our standard enterprise Lync/Skype for IM.
We have an internal reddit-like forum with a "like" model (no dislike/downvote) but it isn't utilized to make work happen. Email is still the way to go...which to my understanding, that's essentially exactly what doist has recreated.
> I think a subreddit would have worked much better.
I'm so used to the reddit and hacker news style that I'd also prefer this as well. This Twist App looks too much like another email inbox[1] to me and that puts me off it. Maybe they could offer ways of changing the UI.
Appreciate your feedback. The Mattermost instance at Startup School does offer threads, if you either click the "Reply" arrow when you hover over a message or go to the "[...]" menu and select "Reply".
If it wasn't easy to discover, that's 100% our fault and we'll see what we can to do make it more prominent in the tutorial and in other ways.
Definitely agree threads are crucial to go back to topics in early discussions. We've had them since 2015 and for people using them, they become kind of indispensable.
Maybe give it a try? Would love to hear your thoughts in the Mattermost feedback channel.
Maybe I misspoke. Maybe I meant "tree view" and not "thread".
I was aware of the reply feature, and yes, if you read a reply and you click on the original title, you get to see all messages attached to this original message, in a window to the right, that you can navigate (more or less).
But AFAIK you can't reply to a reply (if you do, it's a reply to the original message); it's probably a feature (back in the days, the Joel on Software forums worked like that, and Joel Spolsky was actively defending this option in various posts).
But it makes it difficult or impossible to actively monitor different threads or topics. Threads are not collapsible. The UI actively favors the more recent messages, you have to actually click on "load more messages" to see earlier messages (and if you change channels and come back, the earlier messages are gone, you have to click again to see them).
Anyway, I don't mean to be negative on the product which is very well polished and works perfectly; it's just that the choices that it makes seem ill suited for a very international and asynchronous crowd.
We have seen many of these challenges over the years and set out to build something to help manage your team's incoming requests — directly in Slack. We find it's most used for internal assistance (one team supporting many) or as a way for B2B companies to provide support to their top customers.
The goal is to help your team be available and responsive without compromising productivity. To achieve this, incoming requests to a particular team are collected in a "feed" channel. The notifications ping specific people on rotation or on a sequence (according to rules) until claimed, the conversations are explicitly resolved with a "closed" action. We provide assistance for things like inserting knowledge base and template responses, and tagging the conversation. Integrations via Zapier mean a conversation can easily turn into an Asana task, Github issue, etc.
If you're struggling to manage the chaos, give it a shot and see whether it helps.
hard to say - i was mostly using it to communicate with opensource developers on nhibernate (iirc, long time ago). I think you are right though, most of the features are things you'd use more for business. Also considering how widely google docs is used, it makes sense.
Easier to give / remove participants and automatically give them access to previous messages in the thread, without having to quote all previous messages just to give some context.
Apple took a step in the right direction with the do not disturb feature in the Notifications bar. When I don't want to be bothered, I turn it on, when I want to be chatty I turn it off. The next step should be apps that are aware of your do not disturb state and update your presence (as an option) when it's set. Then, I want a timer so I can get blasted with updates every 25 minutes like Pomodoro timer.
I like it. Basically the design choice was to focus on threads within channels, instead of simply channels. Slack has that thread feature but I never use it because it's hard to follow. I guess slack could copy them and have a "text mode" and a "thread mode", easily being able to switch between both, and then the threads will be much more useful.
This looks like a great tool, particularly the ground-up focus on threading and giving teams more options. As with its competitors, it can still easily become just another distraction when people use it wrong.
It's easy to see how you could design a "process" around using something like Slack to achieve the same experience and if you don't design a "process" for using Twist then it will suck just as much. We tried to heavily use channels in HipChat as a threading and noise-avoidance mechanism, it worked well but we often ended up with a lot of channels with the same people in; at which point discipline becomes stressed.
I think that Slack (or any other IM client for work, really) is just a tool, not a solution. Meaning that it requires some organization and thought, rather than installing and hoping for the best. At least to some extent (i.e. have no idea about companies with hundreds of engineers online), it works. Equally important it is to acknowledge what is suitable for doing on IM and what is not.
If you want to discuss some large changes, sure, IM is a bad place. Conversation will probably get interrupted, derailed, etc. That's where, in my opinion, things like Google Docs or plain simple GH Issues shine. The format forces into better thought out, longer messages.
For other things, you need to organize the chat rooms. If you have 10+ people and 2 chat rooms (I think slack defaults to #general and #random) then yes, sounds bad. But instead having quite a few chat rooms with <10 people each might work out well. Even having multiple rooms with the same people can be good to separate different topics of conversation.
"Always on", I believe, comes not from the IM itself but from the culture of the company. I know places where everything is e-mail only and people constantly refresh it. Equally, IM is mostly ghost town outside working hours at other places. And Slack has decent notification settings to make sure that you don't go crazy.
So, IM has it's place and provides value if you are willing to make it work. It's just not a 'it just works' solution, which is hardly surprising.
I cant help but draw parallels between this and NNTP. This is essentially a really nice skin over newgroups, and thats not a bad thing at all. We have seen just how successful a modern UX can be on a old protocol with slack providing a UX to IRC. It is funny that we are slowly reworking the tools of the early computing community in slick modern ways.
It is also interesting that we as a community have completely sold out federated independent operators with a common standards defined protocol for soloed tooling.
This seems like a real missed opportunity to build on systems that already work. I'd love to see these open systems like nntp come back. I hope someone puts in the effort to make them competitive in the modern technology world.
Congrats on finding a real problem and building something to solve it. You're about to fight an uphill battle.
Here's my feedback (from someone who currently leads the leads of 7 remote engineering teams):
• Not knowing if someone is available and if they will get back to you soon is very very bad for many conversations. For example, when you have a C-level asking for rapid turn around on something that needs to be done by someone multiple levels away from you.
• In remote teams, sometimes people disappear (e.g. car accident or civil unrest in a random country), and if you have no way to know, you'll eventually get fed up.
• The feeling of cohesiveness that comes from having realtime conversations, brainstorms and other collaboration is very important to managers (especially in remote teams) and convincing them that realtime talk is not a good default is going to be quite hard.
• As a result you will never be their default communication channel - at most you'll be the place they discuss bigger problems. But because you're not the default, you'll get destroyed by slack, who is the default. Most times people use the tool at hand that they are most familiar with, not the best tool for the job. I would encourage you to write a slack bot that reminds people to use you & helps them easily experience value from your product without you having to win the default spot.
• Finally, most people will have serious difficulty seeing the difference between your product and other product management tools that allow commenting in detail on issues being discussed.
One interesting challenge with this real-time vs. async communication challenge is that different job roles have different needs. At my company, most of our employees have been on the customer service side until recently, and Slack is great for them. Almost everything they need to talk about is urgent (even if it's not important) and temporary. They rarely have long-lasting high-level conversations.
Now we're starting to hire more developers and I'm realizing how disruptive it is for them to be pulled into Slack conversations all the time. So I've started using email more for communicating with the devs, and that seems to work reasonably well.
The questions I have are: (a) is it possible to have a single communication tool that handles both real-time and async properly and (b) does that even matter? Maybe email+Slack is a perfectly fine solution. Either way, it's obvious that only using Slack isn't a viable option.
I don't believe that one should try to create a single tool that covers both synchronous and asynchronous. Their UX is too different.
It seems to me a better idea to create an asynchronous deep collaboration tool and integrate it with synchronous tools like Slack.
The bigger question to me is what should an asynchronous deep collaboration tool do (if anything) beyond first-class threads.
In my mind the opportunity lies on three dimensions
1) Bringing updatable content and structure to threads. This makes threads vastly more useful for real collaboration (not just communication).
2) Making "catchup" much more efficient as this is the main problem with email.
If you think of one of the most successful asynchronous collaboration approaches, it's source control like git. The key thing that these tools to is make changes "diffable". That allows users to work at completely different points in time and still easily "catchup" with what's changed.
3) Allow regular users to easily convert unstructured one-off threads to semi-structured template threads. This naturally and gently moves teams to greater process-orientation.
pretty much our whole company uses irc for real-time communication, and I don't see that going away any time soon. it's lightweight and does what you need it to
The biggest drawback of a real time communication tool like Slack is the React v/s Respond conundrum.
Productive communication and teamwork requires that we respond, rather than react.
What happens specifically with tools like Slack which start off as demi-official tool and then transcend to official is that, one gets into the habit of reacting, instead of responding.
I have personally seen this "fastest finger first" played, almost always.
There has been tons of literature written on reacting v/s responding and I need not dwell into it.
Another aspect is that there is no exit, once Slack is the primary communication tool. One is forced to use it, otherwise you are like an outcast and people more often tend to take it as a signal that the person is on its way out and hence moved away from Slack.
Rest of the drawbacks is documented in the article.
Event: Your boss shares an article on @channel at Slack.
Reaction:: Since our boss has posted it and you don't want to be seemed a second rung player and the one who is NOT on her/his toes, you jump on the keyboard and first "Like/Thumbs Up" that post and then comment for the heck of it, something like "Wow", Amazing", "Insightful".
Then you look over your back ie, to see how many others have commented before you, and if you hardly see any, then you pat yourself on the back and consider the day to have been well spent.
Response:: You read the article once and decide whether it concerns you or to be discarded.
If it concerns you, you read it once more, may be twice and take relevant notes.
Then you decide, whether you should discuss this over an email to your boss, or a personal meeting would be more appropriate.
And thus, you draft an email or ask for 10 mins of private time with your boss.
Maybe some people on the corporate ladder are like this, but I just can't imagine giving a damn about making sure I see the latest article my boss has posted to Slack. I have work to do so that I can clock out and work on my own things. If bossman wants me to see something he better just email or text me.
Slack has its pros and cons, but these are largely the same pros and cons as any instant group communication platform. If one is depending on Slack too heavily for non work-related content then they have separate issues that need dealing with.
At hindsight, if you look at a Slack channel, so much information would be found redundant.
It is there just because it is so easy to put out there, because of the intrinsic nature of the medium, and it is so because, most of it is reaction.
Like, oh this is nice, let's put it out on Slack.
While writing an email,when the communication is being initiated, there is sufficient pause built in the system, to let one ponder, is this really worth it?
Email is not fool proof either of this syndrome, but far better.
What makes email inherently better for your React/Respond dichotomy?
What prevents redundancy is searchability. Most email clients are great for that, but Slack's searchability is inherently better than email - if you're not part of a channel (because you weren't on the team at that point), posts can be searched once you do gain access to the channel.
Emails between other team-members excluding you cannot since you will never have access to them.
There are so many times I just link back to a previous answer on the topic and just h/t the original poster. Takes a moment, but is far more definitive.
If my boss posts something I will assume they found value in it and thinks it is worth the time of X people to read it for information. If they have a question about it, they will ask.
If reading it right now matters, they will say so.
If they are just trawling for likes and noticing who posts something first, I will find a new boss.
I ignore stuff our CEO posts all the time. there isn't a pretense that everything he shares is a big deal, and if it is something important he'll send in an email or mark it as such.
might just be our culture though, there's aren't really any "jockeying for position" situations.
This seems like the hallmark of a pre-dysfunctional workplace. None of the engineering managers I've worked with wouldn't expect their engineers to drop what they're doing and look at an article. All but one were too busy themselves to be doing that sort of thing. None would want to jeopardize their schedules by distracting their engineers. Most managers aren't trying to be friends with their engineers; they have their own friends.
Maybe this is common in startups or in teams where the manager expects to be friends with their engineers. I suppose I've been fortunate to never be put in the situation where chatting with the boss overrode doing solid work.
I cannot relate to the parent post at all. My boss shares content all the time on Slack. People rarely respond, nor is it expected, nor is the lack of expectation communicated, it's just implicit based on the culture. (i.e. "Check this out if you have time")
If my boss was sharing content and then my coworkers were "looking over their backs" to see who liked something first or liked something with enough enthusiasm, I feel like a lot of other things would also be wrong with that work environment to make people behave that way.
I believe this has nothing to do with the workplace. The same thing never happened on email.
If the workplace or culture would have been like that then, a group email sent by the boss/CEO would have solicited the same response.
On Email always worked like, it was email, for those it mattered, they responded and rest carried on with their work.
The vast majority of my usage of tools like Slack, as well as my teams's usage, would fall under the response paradigm you described above. Maybe it's because we're remote workers and we appreciate the fact that we don't have to engage in silly political games like the one you mentioned in the reaction scenario.
"Productive communication and teamwork requires that we respond, rather than react."
I argue if you're too lazy to do both at nearly concurrent times then you might not be suited for that line of work.
I have no problems handling upwards of 10 concurrent 'lines' (aka customer input or manufacturer input issues) on my own. Systems for this exist. Learn about them and use them, or fall by the wayside. These complaints are the complaints of those from the 90s.
"Productive communication and teamwork requires that we respond, rather than react."
I argue if you're too lazy to do both at nearly concurrent times then you might not be suited for that line of work.
I have no problems handling upwards of 10 concurrent 'lines' (aka customer input or manufacturer input issues) on my own. Systems for this exist. Learn about them and use them, or fall by the wayside. These complaints are the complaints of those from the 90s.
"I have personally seen this "fastest finger first" played, almost always."
There's your problem - typing first.
Put everyone on a voice/video collab stream. Now at least you get to hear what's being suggested first like a real office, and respond without having to move away from your work window. "That idea is nonsense, it won't work within our framework guidelines for x reasons." Bam no waiting for people to read what they should be hearing in the first place.
No wonder nobody wants my solution - everyone's too busy listening to the hype of programs instead of the soundness of their workflow.
As a counterpoint, I've used Slack for nearly two years (across several companies at one time or another), and I've never observed this.
I did observe that some employees would consistently answer more quickly than others, but I never saw unsubstantive responses, and it didn't appear to have a chilling effect on people who responded afterwards or the overall result of the discussion.
219 comments
[ 3.0 ms ] story [ 240 ms ] threadIt 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?
Jokes aside, the article did hit the nail on the head in its critique of realtime comms. That said, there was always a subset of any team that seemed to have cold feet / anxiety / or other resistance to writing the longer-form messages of newsgroups.
I think if I had to pick between shallow, but broadly used comms, and slow but heterogeneously used comms, I'd still pick the latter.
I can't believe that they even wrote a new app when they could just have installed mailman, or any other mailing list server, or even a news server.
If I were to create a company I would create mailing lists for discussion and a wiki for consolidation of knowledge. In my humble opinion, there is no need for new fancy apps. The tools are there.
What does the new app they created provide that cannot be done with the tools I mentionned?
I feel old. I'm 36 years old and I see too many articles of people discovering stuff we discussed at length in the 90s. This IRC vs Usenet discussion is an old one.
In my opinion the chat model is simply bad for effectively distributing useful information because it disappears in the noise.
Perhaps what's needed is a combination of the forum-style threaded conversation model for information sharing and work conversations and a chat room which is explicitly for the water-cooler stuff, so that people don't have to be always-on (and constantly interrupted). It should be safe to turn off when you need to focus.
Work communication isn't a technology problem as much as it's a human problem.
Just off the top of my head here are a few types of communication that need to happen at work. In modern work we can assume not everyone can be in the same physical space.
* solve an important problem right now
* find consensus on a complicated problem where opinions vary and emotions run strong
* info everyone needs to be aware of now
* info only a few people need to be aware of now
* info that might be of use within some time horizon for few or all
* relationship/trust building (small talk, gossip) don't dismiss the value of this one
I was cynical about it to begin with, when it was just 'Facebook at Work' but I do believe it addresses a lot of the issues brought up in the blog post and the Workplace team are executing very well.
Accounts are completely separate from Facebook, no crossover at all.
I don't think it's a Slack killer, as they both solve different problems in different ways, and Workplace is very much a 'big co, top down' approach.
I do think other existing collaboration tools have a lot to be worried about between Slack & Workplace though.
Last stat I heard was there is over 14k companies using it.
Maybe Slack should be worried too. They may have a tough road ahead growing into the valuation between Facebook Workplace, Microsoft Teams, Atlassian HipChat and Amazon Chime.
This was the claim that was made when we tried out FB@W, but shortly after I created my work account (I don't have a personal account) my wife started getting friend suggestions for coworkers of mine she's never met. I never even used my @work account for looking at her FB account, wasn't friended to her, etc.
I think it was either a) harder to undo all the creepiness, or b) they didn't want to.
On further thought I wonder how much of the problem I have with slack and similar services (of which I actually tangentially happen to work on one) is more of a problem with process and expectations than anything else.
1. You are expected to be on chat, otherwise you suffer the appearance of not working - counter-productive since you are now subject to distracting notifications. If do-not-disturb settings and turning off notifications wasn't frowned upon this might be less of an issue.
2. Important information should be distributed through a more persistent second channel, email or a web-viewable email-list may actually be suitable.
Most open source projects still use mailing lists, which are even better than forums in that everyone can read and write emails in whatever client they prefer.
And yes, it's far better than chat for serious discussions, with a global group of people. You don't want to exclude the Americans from important decisions when everyone in Europe is awake and on the chat in the morning, and vice versa.
I think both systems have their places - if I have a quick question, chat is usually better. For longer more serious discussions, perhaps with code included, email wins.
For quick questions and discussions, irc is hard to beat.
I must be missing something, I've always found mailing list UIs frustrating to navigate and explore. Does anyone maybe have a primer on how to get the most out mailing lists for someone not already intricately familiar with them?
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 threaded like email, but stored in a single location, so storage/duplication/deletion aren't problems, and indexed searching is available. This also allows things like tagging someone into a thread after it already started.
This doesn't make any sense. If you're subscribed to a mailing list, you will see everything sent to it.
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.
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.
I can't think of any five minute period during my entire tenure where the Slack tab didn't have a little red circle telling me that I absolutely needed to check it right this second. There was no way to filter notifications beyond "Everything", so that little bubble would go up every time anybody in the company pressed a key. 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.
I can't fathom how anybody would have been able to work if they had gone as far as allowing notifications to be turned on and make noises at them every time Slack thought something Important Enough To Interrupt You had happened.
As to mentions and highlight words, I don't think there's a solution for that for muted channels. When I developed this technique I would have liked targetted mentions, but not @here or @channel, which, at the time was indistinguishable. However Slack added a per-channel option to Ignore notifications for @channel & @here, which means I might try the above technique without muting the channel.
Play around with it, you might find the settings can be combined in an optimal way once you understand how they all interact.
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 if they had gone as far as allowing notifications to be turned on and make noises at them every time Slack thought something Important Enough To Interrupt You had happened.
All the notifications and noises can be switched off, and the @channel and @here notifications can be ignored on a per channel basis.
Sounds like a feature that was added in the last 18 months since I last used it. At the time, your options were "every notification about everything, ever" or "no 'notifications' ever, but we'll still helpfully flash the favicon at you all day".
Glad to see there is at least a tiny drip of sanity making its way into the product.
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 point. But past a certain size, I've only ever seen Slacks that a) have a problem with @channel, or b) have a carefully developed and enforced culture of controlling use of @channel.
I think the sophisticated version of this argument is "only experts should use use complex/difficult/dangerous tools". Which is a reasonable argument when talking about, say, wiring up detonators. But Slack's purpose is to connect everybody in a company. Suggesting that Slack is only for experts is to limit its market to a very small segment.
Very few people abandon email because their organisation has a mailing list.
Slack's @channel is exactly the same thing albeit on a smaller scale. If it gets too distracting just tell people not to use it so much.
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.)
Slack, however, is new, centrally controlled, relatively easy to change, and frequently updated. So the email analogy doesn't apply at all.
This x1000
Software is developed and used in a social context. We can't disavow responsibility for the effects our Software cause.
Your company has hammers and screw drivers as your tools. If your employees only know how to use hammers, they are going to hammer screws. If your team only knows how to use screw drivers, they will shrug at nails. Hence, the tool is not always at fault for end user error.
Learning how and when it is appropriate to use the tools at hand is important.
My previous workplace everyone had tight deadlines and goals to meet, they were pressured both internally and externally to act in their best interest, this means that everyone believes their problem is top priority even when it's not a priority at all, and Slack makes communication a billion times faster so they bother whoever they can on Slack.
This usually means one of two things, either going to someone directly or blasting everyone on the channels that contain the entire company, this became the default for us and it was hell, at some point people would notify the entire channel because they couldn't find their mug.
IMO what Slack does, in this case, is expose much bigger issues within the structure of the company, these can't be fixed by switching chat apps.
My current company the communication channels and prioritization are very clear, Slack is not a problem, it is a helping tool.
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 it is we no longer have 100 people shallowly liking us, we now focus on 100 apps shallowly claiming our attention is vital because we are important and we must be interrupted now.
Some of this is probably cultural backlash against automation and bureaucracy and general economic decline. If more people than ever are in fact not useful or important at all, then a communication style focused primarily around telling people they're important, is going to be very popular.
Under that analysis Slack is a post-social communications media, and it constantly rewarding you with endless micro doses of "your attention is valuable" is not a bug, its the whole philosophy of its existence as an app. You can see why curmudgeons see Slack as something negative, like the intrusion of participation trophy culture, because thats pretty much what it is.
The purpose of Slack is to constantly interrupt you with a narrative that you're important. There are incidental side effects that make it semi-useful. Companies spend a lot of money on "make employees feel special" and Slack is merely a modern example of the genre.
This philosophical analysis of Slack is probably extendible past Slack into startups. Don't try to market something as interconnectedness, not in 2017. Try to sell something that symbolically, or whatever, tells people they're important.
Definitely block the spammy apps. It makes a huge different to the smartwatch experience if it's only buzzing for things that really are urgent. Once you tune the notifications, it's actually calming - not only because you're not being interrupted as often, but also because you're not constantly thinking "is there something that needs my attention". If there is, the watch will let you know.
I've never felt the point was for all my notifications to show up.
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.
In our team, some mails are not delivered because Outlook sometimes accidentally autocompletes `John Doe <noreply@github.enterprise.tld>` instead of `John Doe <john.doe@megacorp.tld>`.
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.
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.
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.
10. Has open-source implementations,
11. Allows HTML formatting,
12. Has a hierarchy of topics, splitting up topics in a generic way,
13. Is blazingly fast,
14. AND allows referencing specific articles using an URI scheme: https://tools.ietf.org/html/rfc5538 ?
Exorbitantly fast?
Snappy responsive?
Real-time? (Haha)
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.
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.
"Old" tech is a goldmine.
I have this reaction to _so many_ online services these days.
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.
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).
Expecting people to use Slack in a way it wasn't designed for can only result in failure or constant friction.
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.
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.
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.
one line at a time
no caps or periods
stream of thought
enter each time
I posted a parody of this style a while back:
https://news.ycombinator.com/item?id=11239614
^ as
i never new
* knew
^ is something else
* is to correct
and never use the edit button!
I meant *
thanks
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.
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.
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".
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.
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.
Do you want to spend time training workflow and enforcing best practices, or a tool designed around desired workflow?
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.
Nor should you, really. Imagine trying to do that in an office-based organization! Slack, to me, is a bit like our digital office space.
You can also use highlight words to ensure you don't miss any discussion on topics you're particularly interested in. We have a guy who worked a lot with our billing, and he is magically always present whenever anyone says "refund".
It didn't seem to work well. Since all members of all groups were from all over the world and rarely shared a timezone, no conversation could really take place in real time.
And since there are no threads or topics or anything, it's almost impossible to go back to something that was said a while ago.
I think a subreddit would have worked much better.
We have an internal reddit-like forum with a "like" model (no dislike/downvote) but it isn't utilized to make work happen. Email is still the way to go...which to my understanding, that's essentially exactly what doist has recreated.
I'm so used to the reddit and hacker news style that I'd also prefer this as well. This Twist App looks too much like another email inbox[1] to me and that puts me off it. Maybe they could offer ways of changing the UI.
[1] https://cdn-images-1.medium.com/max/1000/1*zI94S5XizoB4WickR...
Appreciate your feedback. The Mattermost instance at Startup School does offer threads, if you either click the "Reply" arrow when you hover over a message or go to the "[...]" menu and select "Reply".
If it wasn't easy to discover, that's 100% our fault and we'll see what we can to do make it more prominent in the tutorial and in other ways.
Definitely agree threads are crucial to go back to topics in early discussions. We've had them since 2015 and for people using them, they become kind of indispensable.
Maybe give it a try? Would love to hear your thoughts in the Mattermost feedback channel.
Maybe I misspoke. Maybe I meant "tree view" and not "thread".
I was aware of the reply feature, and yes, if you read a reply and you click on the original title, you get to see all messages attached to this original message, in a window to the right, that you can navigate (more or less).
But AFAIK you can't reply to a reply (if you do, it's a reply to the original message); it's probably a feature (back in the days, the Joel on Software forums worked like that, and Joel Spolsky was actively defending this option in various posts).
But it makes it difficult or impossible to actively monitor different threads or topics. Threads are not collapsible. The UI actively favors the more recent messages, you have to actually click on "load more messages" to see earlier messages (and if you change channels and come back, the earlier messages are gone, you have to click again to see them).
Anyway, I don't mean to be negative on the product which is very well polished and works perfectly; it's just that the choices that it makes seem ill suited for a very international and asynchronous crowd.
The goal is to help your team be available and responsive without compromising productivity. To achieve this, incoming requests to a particular team are collected in a "feed" channel. The notifications ping specific people on rotation or on a sequence (according to rules) until claimed, the conversations are explicitly resolved with a "closed" action. We provide assistance for things like inserting knowledge base and template responses, and tagging the conversation. Integrations via Zapier mean a conversation can easily turn into an Asana task, Github issue, etc.
If you're struggling to manage the chaos, give it a shot and see whether it helps.
http://frame.ai/beta/
PS: I am a google employee.
TLDR: emails are messy, siloed, opaque, not easily shared
It's easy to see how you could design a "process" around using something like Slack to achieve the same experience and if you don't design a "process" for using Twist then it will suck just as much. We tried to heavily use channels in HipChat as a threading and noise-avoidance mechanism, it worked well but we often ended up with a lot of channels with the same people in; at which point discipline becomes stressed.
What's your sense of how Twist and Basecamp compare?
We wanted to create a product that just does one thing really well (and that's team communication).
If you want to discuss some large changes, sure, IM is a bad place. Conversation will probably get interrupted, derailed, etc. That's where, in my opinion, things like Google Docs or plain simple GH Issues shine. The format forces into better thought out, longer messages.
For other things, you need to organize the chat rooms. If you have 10+ people and 2 chat rooms (I think slack defaults to #general and #random) then yes, sounds bad. But instead having quite a few chat rooms with <10 people each might work out well. Even having multiple rooms with the same people can be good to separate different topics of conversation.
"Always on", I believe, comes not from the IM itself but from the culture of the company. I know places where everything is e-mail only and people constantly refresh it. Equally, IM is mostly ghost town outside working hours at other places. And Slack has decent notification settings to make sure that you don't go crazy.
So, IM has it's place and provides value if you are willing to make it work. It's just not a 'it just works' solution, which is hardly surprising.
It is also interesting that we as a community have completely sold out federated independent operators with a common standards defined protocol for soloed tooling.
0 - http://forum.dlang.org/
1 - https://github.com/CyberShadow/DFeed
Here's my feedback (from someone who currently leads the leads of 7 remote engineering teams):
• Not knowing if someone is available and if they will get back to you soon is very very bad for many conversations. For example, when you have a C-level asking for rapid turn around on something that needs to be done by someone multiple levels away from you.
• In remote teams, sometimes people disappear (e.g. car accident or civil unrest in a random country), and if you have no way to know, you'll eventually get fed up.
• The feeling of cohesiveness that comes from having realtime conversations, brainstorms and other collaboration is very important to managers (especially in remote teams) and convincing them that realtime talk is not a good default is going to be quite hard.
• As a result you will never be their default communication channel - at most you'll be the place they discuss bigger problems. But because you're not the default, you'll get destroyed by slack, who is the default. Most times people use the tool at hand that they are most familiar with, not the best tool for the job. I would encourage you to write a slack bot that reminds people to use you & helps them easily experience value from your product without you having to win the default spot.
• Finally, most people will have serious difficulty seeing the difference between your product and other product management tools that allow commenting in detail on issues being discussed.
Now we're starting to hire more developers and I'm realizing how disruptive it is for them to be pulled into Slack conversations all the time. So I've started using email more for communicating with the devs, and that seems to work reasonably well.
The questions I have are: (a) is it possible to have a single communication tool that handles both real-time and async properly and (b) does that even matter? Maybe email+Slack is a perfectly fine solution. Either way, it's obvious that only using Slack isn't a viable option.
It seems to me a better idea to create an asynchronous deep collaboration tool and integrate it with synchronous tools like Slack.
The bigger question to me is what should an asynchronous deep collaboration tool do (if anything) beyond first-class threads.
In my mind the opportunity lies on three dimensions
1) Bringing updatable content and structure to threads. This makes threads vastly more useful for real collaboration (not just communication).
2) Making "catchup" much more efficient as this is the main problem with email.
If you think of one of the most successful asynchronous collaboration approaches, it's source control like git. The key thing that these tools to is make changes "diffable". That allows users to work at completely different points in time and still easily "catchup" with what's changed.
3) Allow regular users to easily convert unstructured one-off threads to semi-structured template threads. This naturally and gently moves teams to greater process-orientation.
I'll be answering your questions. Thanks for the support!
Productive communication and teamwork requires that we respond, rather than react.
What happens specifically with tools like Slack which start off as demi-official tool and then transcend to official is that, one gets into the habit of reacting, instead of responding.
I have personally seen this "fastest finger first" played, almost always.
There has been tons of literature written on reacting v/s responding and I need not dwell into it.
Another aspect is that there is no exit, once Slack is the primary communication tool. One is forced to use it, otherwise you are like an outcast and people more often tend to take it as a signal that the person is on its way out and hence moved away from Slack.
Rest of the drawbacks is documented in the article.
Reaction:: Since our boss has posted it and you don't want to be seemed a second rung player and the one who is NOT on her/his toes, you jump on the keyboard and first "Like/Thumbs Up" that post and then comment for the heck of it, something like "Wow", Amazing", "Insightful".
Then you look over your back ie, to see how many others have commented before you, and if you hardly see any, then you pat yourself on the back and consider the day to have been well spent.
Response:: You read the article once and decide whether it concerns you or to be discarded. If it concerns you, you read it once more, may be twice and take relevant notes. Then you decide, whether you should discuss this over an email to your boss, or a personal meeting would be more appropriate.
And thus, you draft an email or ask for 10 mins of private time with your boss.
Slack has its pros and cons, but these are largely the same pros and cons as any instant group communication platform. If one is depending on Slack too heavily for non work-related content then they have separate issues that need dealing with.
If you want reasoned discussion, there should be an ask from the boss on the channel-toss even if it is a @TheRealmccoy call-out on the posting.
At hindsight, if you look at a Slack channel, so much information would be found redundant.
It is there just because it is so easy to put out there, because of the intrinsic nature of the medium, and it is so because, most of it is reaction.
Like, oh this is nice, let's put it out on Slack.
While writing an email,when the communication is being initiated, there is sufficient pause built in the system, to let one ponder, is this really worth it?
Email is not fool proof either of this syndrome, but far better.
What prevents redundancy is searchability. Most email clients are great for that, but Slack's searchability is inherently better than email - if you're not part of a channel (because you weren't on the team at that point), posts can be searched once you do gain access to the channel.
Emails between other team-members excluding you cannot since you will never have access to them.
There are so many times I just link back to a previous answer on the topic and just h/t the original poster. Takes a moment, but is far more definitive.
If they are just trawling for likes and noticing who posts something first, I will find a new boss.
might just be our culture though, there's aren't really any "jockeying for position" situations.
Slack is for small teams which have a lot of shared context
Maybe this is common in startups or in teams where the manager expects to be friends with their engineers. I suppose I've been fortunate to never be put in the situation where chatting with the boss overrode doing solid work.
If my boss was sharing content and then my coworkers were "looking over their backs" to see who liked something first or liked something with enough enthusiasm, I feel like a lot of other things would also be wrong with that work environment to make people behave that way.
Our boss actually uses e-mail for this purpose, which I find much more appropriate because it matches the "if you have time" bit better than Slack.
On Email always worked like, it was email, for those it mattered, they responded and rest carried on with their work.
I argue if you're too lazy to do both at nearly concurrent times then you might not be suited for that line of work.
I have no problems handling upwards of 10 concurrent 'lines' (aka customer input or manufacturer input issues) on my own. Systems for this exist. Learn about them and use them, or fall by the wayside. These complaints are the complaints of those from the 90s.
I argue if you're too lazy to do both at nearly concurrent times then you might not be suited for that line of work.
I have no problems handling upwards of 10 concurrent 'lines' (aka customer input or manufacturer input issues) on my own. Systems for this exist. Learn about them and use them, or fall by the wayside. These complaints are the complaints of those from the 90s.
There's your problem - typing first.
Put everyone on a voice/video collab stream. Now at least you get to hear what's being suggested first like a real office, and respond without having to move away from your work window. "That idea is nonsense, it won't work within our framework guidelines for x reasons." Bam no waiting for people to read what they should be hearing in the first place.
No wonder nobody wants my solution - everyone's too busy listening to the hype of programs instead of the soundness of their workflow.
We're just waiting for you to post it in the form of a sound recording :)
The problem is that there is no inherent pause built in the system.
It's boon is its bane!
I did observe that some employees would consistently answer more quickly than others, but I never saw unsubstantive responses, and it didn't appear to have a chilling effect on people who responded afterwards or the overall result of the discussion.
I feel old.