Slack also has other problems that have been totally ignored and neglected for years. One of them is accessibility. The app is impossible to work with without a mouse. They say it is "keyboard driven" and they keep adding features that ignore keyboard completely. Have you ever tried to jump to a thread without using the mouse? Or copy a link to the last message? Or share it? Or ask Slack to remind about it? Or snooze all notifications? They could at least put them in the main menu. People with disabilities who rely on things being in the menu, they can't do any those things. Can you imagine having to hire someone and they'd be like: "Ah sorry, I have to tell you something. I cannot use Slack app. I hope that's not a deal breaker". I wouldn't be surprised if someone sues SlackHQ for being discriminatory.
Blind user here. I find Slack impossible to use. With more and more communities moving from IRC to Slack, I also feel the exclusion these days. Technologies/Companies like Slack make me wonder how long I will be able to usefully participate in the tech online. Watching how accessibility is systematically forgotten these days, I am not very hopeful.
I spend at least a few hours every week talking & gathering feedback from customers with disabilities. What I've learned, beyond the fact that our screen reader experience is not great (yet), is that we're not doing a good-enough job communicating the a11y improvements we've made. And because of this some users (particularly screen reader users) are sticking with the work-arounds from back in the day when our a11y support was indeed worse.
If you feel like it please write in to feedback@slack.com and we can set up a meet. I'd love to learn what we're doing wrong and potentially go through the support & improvements we've built.
This article should help as well. It's documenting not just the shortcuts but also how to perform different flows.
How accessible are open-source slack competitors like Mattermost?
I feel for you. I'm blind in one eye and am at a pretty high risk of going blind in the other because of it. I do my best to make sure the things I build are accessible; it's a real shame that accessibility is typically an afterthought.
We made a bot for slack which provides voice summary for web pages, it is invoked by @larynxBot [URL] to get the audio summary of web content right inside slack[1].
I didn't specifically target this as utility for visually impaired users(as we weren't able to test with such users), but was under opinion that it would help them if someone from the team shared links with our bot.
Reading your comment & that of others reg accessbility on slack makes me wonder if even when audio summary of URLs is received, whether someone with accessbility issues can click the player button.
Blind users already have their favourite screen readers. There is almost zero need for custom audio summary or alike features. Those are feature from sighted people for sighted people. But they have almost zero relevance to people relying on accessibility.
To answer that, I'd need to know what you actually mean by summary. Most screen readers present an overview of the number of HTML elements in a page when it just loaded. Something like "5 headings and 28 paragraphs".
Why would you want to provide audio summary of a page in the first place instead of providing a text summary? Reading text is about 2.5 times faster than listening to speech. And regardind accessibility, blind people can use their screenreader to get an audio version of the summary.
On the same topic: your landing page does a bad job of displaying what your app does and why it is useful for me as a user. I had to watch the "how to use" video to get an understanding.
larynxBot is part of the larynx platform, where one could share any content along with their own voice.
Users who received larynx content said they liked the voice summary of web content which their contacts sent to them & asked for a feature to summarise web content on-demand.
Hence, we released it as bots for Messenger, Telegram, Twitter & slack. I agree that the website portion of larynxBot can do a better job at explaining it.
Hi mlang23. The Slack screen reader experience isn't perfect but we've made significant improvements that it's usable, according to our testing & talking to screen reader users working for our customers. My colleague, and until recently our biggest critic, has documented our accessibility journey here (from a user's perspective, of course): https://marcozehe.wordpress.com/2016/01/16/status-of-the-acc...
I would like to flog a (still live) horse and point out that Discord is even worse. I would even go as far as to say that Discord’s design is aggressively thoughtless for the visually impaired.
My company uses Discord for comms and I’m active in several Discord communities, but my vision impaired co-worker isn’t. Not because of a lack of want, but because Discord has been coasting on accessible design for years. https://www.reddit.com/r/discordapp/comments/4tn00z/when_wil...
Everything takes more resources than we expect, but surely a theme for their client (we do have some proof that it is theme-able) that is friendlier for screen readers shouldn’t take more time than an entire games store?
For me, the big takeaway from hearing about Slack’s issues and contrasting it with Discord is that people just don’t seem to care. And that’s often the status quo until an Apple comes along. We forget this, but back before the resurgence of Apple, design was an afterthought, not a forethought even though there were obvious gains to be had and a better future to lead towards. But the vast majority of companies avoided the obvious win until Apple’s stock price shocked them into caring.
A significant fraction of everyone’s user base (including the core users) would benefit from accessible and thoughtful design, because like the article says, we’re all disabled sometimes. Now, we just need to figure out which company will have to show the world how to do it.
Discord also has a record of cracking down on 3rd party clients, so if someone wanted to make a more accessible text-based replacement for their electron app, they can't.
Most UI designers don't care about accessibility either. In fact, I would say that many designers have aesthetic preferences that are actively hostile to accessibility.
> I would even go as far as to say that Discord’s design is aggressively thoughtless for the visually impaired.
I'd take that further. Discord's UX drives me to despair. It's like no other chat app (which is my basic use-case). Multi-party voice is awkward, much of the interface doesn't lend itself to self-explanation, etc.
edit: The reason for using discord vs anything else is the need for a voice chat app in-game since some party members have issues with steam, and what other decent options are there that don't require self-hosting?
My name is George Zamfir, I'm the Accessibility PM at Slack. I recorded a quick gif that shows how Slack works by keyboard, which covers the scenarios you mentioned as well.
Here's a quick description of what's happening in the recording:
The following is all you need to get around Slack by keyboard (and as an extension, with a screen reader):
F6 to jump around the large UI sections, TAB for going through focusable elements, UP/DOWN for reading through messages in the message list / threads pane / Search / All Unreads / Threads, PGUP/PGDOWN/HOME/END to scroll through messages.
And lastly Search (`Cmd / Control + F`) now also allows jumping to users / channels / workspaces / etc. on top of regular search.
Thank you for this comment. Indeed it shows that you guys do care. I did not know about <F6>. Can I make a few suggestions?
- Would it be possible to duplicate <F6> so it can be initiated without having to move one's hand? Also latest Macbooks don't even have F-keys.
- When in F6-mode, would be nice if it was possible to navigate using h/j/k/l (Vim users would appreciate)
- Also would be nice to be able to start (jump to) a thread in F6-mode by pressing a key, maybe <T>, or react with emoticon by pressing <R> maybe? Having to press <Tab> multiple times is not only annoying, it's inconsistent - when you are in a thread there are different actions compared to when you are not.
---
I have played with F6-mode and tried navigating with it. It is still quite difficult to use the app and you are still forced to use the mouse. And I'm not even visually impaired. Can you imagine how hard it is for people who are?
In general, I wish PMs at SlackHQ were forced to use Slack app once a week without a mouse - where only keyboard is allowed.
Indeed. I worked with a fully blind colleague(who ironically did accessibility testing..) - it made me so sad he couldn't participate in all the stuff on Slack. I mean yeah he'd get an email if it was important, but surely he must've felt excluded frequently.
> Indeed. I worked with a fully blind colleague(who ironically did accessibility testing..)
I don't know that that's ironic. Doing accessibility testing without significant impairment is very, very difficult, because you take shortcuts an impaired user doesn't get to use without even realising it. An impaired user can "just" try to use the software and they'll smash their face straight into all the roadblocks and sharp edges.
For blindness it is relatively easy to simulate for a sighted person as long as the blindness they are trying to simulate is total rather than partial, just turn the screen off.
But a sighted user will be much less proficient at using anything like that, so it is probably better to find someone who isn't sighted and so does everything like that. Otherwise it will take far longer to recognise any issues
> But a sighted user will be much less proficient at using anything like that
Not only that, but they'll be stumbling around not really knowing how vision-impaired users actually work with their devices, so they would have issue an impaired user would not have, and not hit issues an impaired power-user would.
They're big enough for this to become a legal issue at some point. It's a shame if it had to come to that, but the broad adoption would create a strong case. Personally, I take pride in developing applications that accessibility-friendly. Because even I don't want to use a mouse sometimes -- it benefits sighted users too, and anybody who wants to work more productively without the mouse.
Before a case like this would ever go through and have a positive effect, thausands of vision impaired people worldwide have already lost their job or could not begin a new one because of lack of accessibility of these platforms. The damage has already been done / is ongoing. And disable people already have a hard time finding a job. So this damaging to those that already have a hard time to cope in our society. Slack and Discord are actively toxic. And nobody cares / waits for a court ruling. That is why I said I dont see much light here. The tech industry is in the process of selecting out those that have visual disabilities. Not just because of Slack and Discord. The general trend of moving everything ith browser is death by thausand cuts for people with visual disabilities. It doesnt matter if I am forced to use Slack or SharePoint, or your favourite commercial issue tracker. Almost all modern pwb based products reduce my productivity to almost zero.
You wouldn't be suing your company. You'd be suing the company the makes the software your company uses. There'd be no political risk at your employer.
I'd imagine the first step would be a quiet word with HR. If they are in any way good at their job, they will do the work for you, as their job is to protect the company from tribunals.
Press Ctrl+K or Ctrl+j shortcut to go to a chat, then the text field isn't even focused! FFS what's the point of the shortcut then, if I have to grab the mouse to click on the input anyway, just to get back to the keyboard immediately.
> Tab gets you there. maybe not fast, but it does.
People choose keyboard-centric workflows:
a) For efficiency (if it takes a few milliseconds to press a key, why would you even reach for the mouse?)
b) For accessibility
Your point is not helpful for any of these cases. Asking to try to use Slack App with a blindfold might be a bit extreme, what if I suggest you to try to use it for a few hours without touching the mouse? How's that for a challenge? Try that and maybe then you'd feel how it supposed "to get you there" for people with disabilities.
> The app is impossible to work with without a mouse.
It is, in fact, not.
I disagree that it's super difficult, but even if so, difficult is substantively different than impossible.
You, on the other hand, decided to pretend I said something I didn't so you could be indignant and tantrum at someone who... doesn't work on Slack and makes zero decisions about what to implement in the Slack app.
Alright. You are right, I re-read my reply to you, my tone indeed looks indignant (wasn't my intention), you haven't said anything that merits such tone, I apologize for that. But I stand by my words: Slack app is impossible to work with without a mouse for people with disabilities. The very first reply to my original comment confirms that.
Slack dev here. We've actually fixed quite a few accessibility issues over the last year or so. There's still a ton to do, but if you haven't used Slack with a keyboard recently, give it a whirl.
I used recently and it's impossible to use with keyboard only, you can try yourself.
During duty shifts I was helping our support. The incoming flow of requests had peaks of ~3-4 situations per minute, all as messages in Slack channel, needed to be responded in newly created thread each. I've come up with a flow, but I cannot avoid mouse at all.
Slack just does not have enough key bindings to be used without mouse! Slack was a bottleneck for me.
If you are not willing to invest into UX that's fine to have gateways for people to use whatever client UI they need. But you just cannot wear to hats by both removing gateways and avoiding investing into your client UX. Result is plainly awful.
Nothing personal, I am actually hate using Slack, sad to say that. I will avoid using Slack in current state at all cost whenever I can.
Good luck to you! Hope you will make your product better!
SlackHQ, we are software developers, devops and QA engineers, data scientists and IT support specialists - we are your biggest user base!
When we say it is not working, please, listen to us.
Please, do try using your app without the mouse and maybe then you will see what we are talking about.
It is not a baseless demand, our companies pay to use your service. If your codebase was open-sourced we would've fixed this issues ourselves.
Please, don't make us hate you. When you just started you were awesome, but now you are slowly turning into Atlassian.
If you're allowing your client to be multi-protocol then why is Slack's protocol unsuitable? You can use weechat with the Slack API right now and it works great.
The market for 3rd party applications using Slack is huge.
We need a federated communication protocol, similar to email, where we can have real-time communication with people and groups on various networks and using differing software.
You really should be building with a11y in mind from the get-go. It's 2019. The tooling is much, much better than it was in years past. It shouldn't be impossible for any enterprise to make a reasonably accessible application.
Nobody even expects 100% perfectly, semantically correct HTML documents. And it takes relatively little work to get reasonably good support. Like anything, the investment has diminishing returns but the 80/20 rule applies.
>Have you ever tried to jump to a thread without using the mouse? Or copy a link to the last message? Or share it? Or ask Slack to remind about it? Or snooze all notifications?
I'm not sure these are issues?
* Not sure what "jump to a thread" is referring to, but you can step through top-level messages with the cursor keys and use <Tab> + <Enter> to activate the "n replies" link.
* You can focus the relative timestamp link (it's got a sensible tab ordering) with the keyboard and then trigger the browser's context menu to achieve this.
* The message's context menu is also tab accessible. The "More actions" link is aria-label'd as you'd expect. You can navigate the subsequent context menu using the keyboard to select "Share message".
* Snooze/remind are accessible via commands, as well as menus which are accessible as described above. The commands are documented in the help.
Have you actually tried using Slack App without a mouse or a trackpad? I mean when I said "impossible" I didn't mean literally. Keyboard driven workflows are meant for fast, precise actions that are suitable for situations where you can rely on muscle memory. That's why POS terminals usually built with a keyboard focused interface. Can you imagine a cashier, holding a whole line because it takes her several minutes to undo a transaction, because she tapped/clicked with a mouse on a wrong item?
SlackApp, unfortunately doesn't allow you to be efficient, because it's not meant to be used without a mouse. Telling that it is, because you can press <Tab> multiple times and get where you want to be - isn't a solution. First, it is inconsistent - number of times you need to press <Tab> varies from the context you are in. And because of that it is not only inefficient, but it is also limiting for people who have no choice but to stick to using keyboard. And for people with disabilities it's pretty much literally impossible.
>Have you actually tried using Slack App without a mouse or a trackpad?
Yes, I tried before I wrote my comment :) My experience informed everything I said.
>SlackApp, unfortunately doesn't allow you to be efficient, because it's not meant to be used without a mouse.
I don't disagree it's probably primarily built with mouse users in mind. But nobody here is concretely discussing what Slack (and by extension, all web apps) can do to make their applications more accessible.
>First, it is inconsistent - number of times you need to press <Tab> varies from the context you are in.
Surely this applies to every application? The number of tabs it takes to get to the address bar in my browser varies based on the current element that has focus. Same for my word processor. How is this supposed to work?
In browsers you can install extensions that can help to navigate efficiently, but Slack App is not extensible that way. The purpose of the app is to allow an efficient exchange of textual information. Not being able to quickly jump to any thread using keyboard - defeats the sole purpose of the app.
Can you imagine to have a code editor that doesn't allow you to change its color scheme? Some may say: "it's not important", but for many people something like that would be a deal breaker. Fortunately we have many IDEs or editors to choose from, but we can't opt out of the Slack app - if the company is using it, you stuck with it.
My only complaint for Slack (and any instant messaging app), is the sense of urgency it creates. It has been discussed on HN a lot, but I 've never seen someone complaint about the fact that you can invite to your organization people from other orgs. This feature is beloved by product managers. And hated by everyone else.
See. Before 'Slack', we had 3 channels of communication.
1. Email (usually expectation of getting a reply within hours)
2. Phonecall (reserved for urgent situations, expecting a reply within... seconds)
3. Ticket system that had a little drop-down where you could select urgency. And you would expect a reply based on the urgency.
If you abused the urgency, we had a way to track that, and let you know.
Today however, Slack's "multiple organizations" feature pretty much shadowed the above. Now product manager from client org X, will require that you make a channel called "X-feature Commandos/dream team" then invite everyone involved on the project. Then they will ALWAYS end up wasting everyone's time for no reason. "Hey @here, X page is slow can you check it out?". "Sorry guys my bad. I was under the bay sea riding the Bart! Forgot LTE connections can be finnicky 100m under water. heh (ultra fast parrot emoji)"
> Then they will ALWAYS end up wasting everyone's time for no reason. "Hey @here, X page is slow can you check it out?"
I don't understand why your company doesn't charge, say, $500 per request like this. Let the client have direct Slack access to you, if that's what you want. Just don't give them your time for free when you make a living selling your time.
I imagine OP was referring to internal partners. I still like the idea, but actually recording how much team time a partner team wastes opens up more problems than it's likely to solve.
I kind of want to turn it off for half the work day to get my time back. As an engineer, it kills getting into a state of flow, which is essential for maximal productivity.
I've gotten the impression that some places force you to be online on Slack all day and therefore receive notifications. Maybe the Slack admin can see if you disabled notifications even, which could mean you get reprimanded. But I'm not sure.
Some places (my company included), invite people from client organizations on slack. You can have cross-org accounts and limited access to another org's slack.
We are sadly utilizing this heavily. Disabling notifications in those channels is not permitted as essentially you are required to reply as soon as possible. They exist for the sole reason of instant communication, which I find counter productive but product-xxx people LOVE.
Those guests will not play by your rules. Those guests will play by their bosses rules, who might err on the side of yelling at you at first chance. Things like "QA didn't catch bug X" people pinging on a friday afternoon, rather than going in the process of opening a ticket.
Again you cannot ignore them, and you cannot change this, because these people are paying you. Usually it's team leads that are present in those rooms, so they get all the shit thrown at them at random times, and can only tell themselves "hey I 'm paid better than average so it's part of the job right?". No, no it's not part of the job. Whoever made this decision is dumb, and Slack unfortunately catered to the wrong feature requests and made this too easy to happen too.
Since I am seeing how trigger happy our product managers are to invite the client org's PMs to our Slack, I can only dream that in an ironic twist of fate when Slack's product people reviewed this feature request they immediately loved it too and on a friday evening pinged the slack team leads to hop on it :p
eh. I disagree. I find that with Slack there's this expectation to reply right away. And if your boss Slacks you, sees you're online, and you don't reply, it's perceived as not doing your job. And even if it's not perceived that way, we've developed our own fears that we'll be judged as being unavailable/ un-responsive or simply not doing our jobs well enough.
It may be cultural and not just app-based, but when millions of people are using a specific app, its hard not to draw conclusions...
IM is really useful lots of times, but I definitely think it's one of the main contributors to our 'workism' problem and what so many of u have issues disconnecting and eventually burning out.
</rant>
This is why I can't imagine using slack (or any kind of chat service) for work, except in very specific circumstances like a team tracking an outage or one-on-one customer support.
Why would you want to be interrupted by inane chatter when you're working?
I had to fight our HR manager over access to @here and it's equivalent.
Global company, people working all sorts of schedules and they want to use @here in the primary channel (which you can't mute) to send inane bullshit about unimportant stuff. (In theory @here only sends notifications when you are 'here', but I found it to be less than reliable)
The first few times people did it, I asked them not to, and then turned it off for non-admins. Thus the fight with HR.
And if you don't reply within 24 hour: fired. By me at least. (don't be silly, I don't have the power to fire anyone anymore).
Yes, expecting a reply by email sooner than e.g. 4 working hours is futile.
But if you work in a team and only communicate once a day then you are not a team member, you are an ar#eh#le.
If you constantly check your emails and slack and write replies immediately then yes, we should probably have a chat about your time focus and productivity. But checking your emails quickly once an hour is common sense. And where appropriate with a quick receipt response, not a full answer.
And e.g. slack every 15 minutes or half an hour. Perhaps in a Pomodoro break or similar. (channel dependent)
It would perhaps be a good idea to have a well-known team/department convention on response times. More asynchronous for email especially if not internal (hours not days). Quite asynchronous in company-wide public slack chats, and more responsive but not instant in team irc-like chats.
Whether you program, write content, make sandwiches etc is no excuse to be an ar#eh#ole.
I reply to say "I will get to this request in x amount of time," and that amount of time simply increases as the requests go up and I factor in time spent focusing and context switching.
I check slack every hour or so. Not because I have to but as a break from coding. However it doesn’t mean I’ll answer every question or switch context.
When the Slack sales team came to my employer they pitched it as some sort of memory store - the reality is that it’s nigh impossible to pick out a specific bit of information after a couple of months unless you remember who said something, where they said it, and approximately when. It’s also annoying when an admin leaves because only the owner can remove their account - not another admin. I would also say Slack has a very bad habit of forcing new features down users throats - people have been complaining about threads for years but there is STILL no way to mute them or disable them. Someone installs an add-in that makes a lot of noise? Tough cookies to you, your options are to put up with it or uninstall it, there is no way to mute it. Like people joining you to new channels? No way to stop that either. Their API is a pain to deal with in staticly typed languages - you often have to decode a member of a substructure to discover what the overall type is. So overall I would say it’s definitely not an e-mail replacement and it’s very heavy handed for IM, there is definitely room for another product. I would personally prefer something more akin to IRC or the classic “cb simulators”. The only real challenge today is working with mobile clients (and challenge is probably too strong a word).
All these complaints about Slack, are strangely reminiscent of all the complaints about email pre-Slack; "re:re:re:re:re:", cc all the people, 200+ non-relevant emails per day etc etc.
I worry that people are trying fix org culture problems with communication software, which is unlikely to succeed.
>I worry that people are trying fix org culture problems with communication software, which is unlikely to succeed.
Agreed. If your work culture demands that you answer every single slack message within 30 seconds, or forces you to be "online" constantly, you have bad work culture. This is not a issue that slack, or email, or texting, or phone calls can fix.
You could argue that slack makes fostering these work cultures easier, and to that I would say it's still just bad management.
Also - and this argument gets brought up a lot by slack haters - if that @here, or other notifications, are so impeding to your daily productivity, you might just have trouble focusing. Which isn't bad, but learn to deal with it instead of blaming Big Bad Slack.
Hint: you can exit Slack and check it once per hour, every few hours, or even once a day. I've yet to see one real life example where people are forced to be online and respond within seconds of receiving a message.
That's exactly why we need to fix email - not replace it with another app with more notifications. I agree with Dvir - email's asynchronous nature is what makes the exact solution for business comms. It's instant, but not invasive, and doesn't expect an instant reply. Culturally, we need to also respect people's time. I'm sticking with email.
Most of the Slack channels I use are used async, and I only have notifications on for 2 out of ~15 channels. Good comms culture was much easier to develop with Slack + [Something for docs] for the teams I have worked with. But I very much understand that teams are different, and different cultures work optimally for different teams.
Slack enabled "De-silo'ing". It became more efficient and convenient to ask a team, or knowledge group of something, instead of depending on specific persons. Easier to be flexible about which topics to follow or not. I.e. normally I don't interact much with the #ops channel, but Bill is on holiday, so I'm giving it attention this week.
On the other hand, there is a case to be made that if everyone makes "mistakes" it's because it's the first option they have, so we (as an industry) should make softwares do the correct thing by default. Users don't have time to fiddle with options, the software should serve them.
I generally agree with that opinion, but in this case I believe communication tool feature sets are not the right setting to enforce organisational culture. You would end up with a highly opinionated piece of software, which would imply that one size fits all, when it comes to org culture.
Slack et al. (and email for that matter), can be used in a myriad of different ways to suit different types of organisations, which I strongly believe is a good thing.
We probably do need software to help us all with org culture, but I don't think comms is the right place to implement that.
Slack is a productivity killer and whatever they are doing next is certain to be annoying. People ping each other asking questions instead of reading docs. People have calls instead of figuring it out. Annoying people just can’t resist the temptation of @here.
It wouldn’t be so bad if I could customize my experience but Slack fights hard against this. They claim one size fits all, if it’s annoying then it’s a cultural issue.
You can’t get thousands of people on the same page. Different mindsets should be fostered, not punished.
I never understood people who get annoyed by @here. If you are somewhere where you don't want to be, and people send a message to you that you don't care about, you shouldn't be there in the first place. We have many channels in our company where complete strangers hang out, for example in the engineering channel like it was a garden party of some sort. You know: just for fun. I mean WTF is wrong with these people? Why are they in the channel if they are not interested? When I message with @here I don't give a shit if it annoys someone or not, as long as the message is completely in line with the channel's intended purpose.
In 15 years as a professional software engineer, I’ve never worked somewhere that wasn’t heavily using IRC, Hipchat, or Slack. The conversations are identical, the only thing that has changed is the service being used. As previous poster alluded to, your complaints aren’t a Slack issue, it’s a co-worker issue.
The nice thing about pre-Slack was that there was a bozo filter: the only people who could bother you were the people who could figure out how to use an IRC client.
Also 15 years professional here; And I agree, it's largely similar.
One difference though is that IRC doesn't have a @here equivalent. People do like to overuse that one in particular. (you can turn it off but the default is frustrating and the UX is poor for disabling)
For whatever reason, most orgs I've seen are terrible at getting people who talk too much to stop, whether it's in meetings, at the work table or in Slack.
I find the opposite, I can often help my coworkers debug something pretty quickly via a quick Slack call and screen sharing session, whereas other times I have seen similar problems resulting in hours of struggle as someone tries to 'figure it out' on their own without being able to tap the expertise of someone who's familiar with the problem or system at hand.
That said, there are definitely downsides to the abundant distractions through Slack as well.
Is there not value to be gained when someone is struggling to get past a problem? I've seen what happens when people too quickly phone a friend whenever they hit a problem, the end result being they don't round out their knowledge.
It depends on the person and the problem I think. I have also seen people sort of struggle and not really make progress and leaving them in their own wouldn’t be a learning experience.
Like how if you throw someone who doesn’t know how to swim in the ocean they might just thrash about until they get tired and drown...
I do always try to work with them to explain the steps I am taking to troubleshoot but it’s definitely a balancing act as you want them to learn not just have it done for them.
I’m in some Slacks that have thousands of people all on the same page. It’s impressive and inspiring how the communication style and culture has developed and is enforced.
The number one point is to recognize the situation as a conflict of interests - everyone wants an immediate answer to his burning question, but nobody wants to be interrupted to answer somebody else questions. For the team as a whole there is probably some optimal interruption level which is higher than what the interrupted would set and lower than what the interrupter would choose. That is why muting and 'urgent' messages don't work - because people would tend to mute channels too much and on the other hand 'urgent' quickly inflates and everything starts to be urgent. I think a solution to this could be "attention budgets". There are many complications of course - there are times when you don't mind being interrupted and times when you do, and it is taxing to think about it consciously and set your levels. But I would start from attention budgets - this would also be a solution to general spam, but synchronous spam is much worse than asynchronous - so synchronous is a good place to start.
I find things like this funny because Email is often much worse for getting ideas across and VERY FEW people put their whole idea in an Email and simply treat it with chat + 6 line signatures. Where I've worked email has simply been a very poor chat which I could not distinguish "info broadcasts" from "the server is down" without getting all notifications or none.
We switched to slack in 2014 because 1) it allowed us to notify mindfully for team-wide and person specific things. 2) it allowed people to have full blown conversations and keep others up to date on status/problems in channels. And 3) it allowed us to build automation right inline with the communication we were already doing.
Much of the complaints of slack seem to be from people who work with those who do not respect how to use it. Spamming @here for everything is the same as replying-all in email. Or, my personal pet-peeve, creating a new private group chat for everything making finding the old conversation nearly impossible.
Discord has tons of improvements I've love to see in Slack namely around groups of channels and role management, but for the most part it seems the problems with slack are organization's unwillingness to understand it's purpose and how to best use it not as a pager system for your whims, but actually as an async communication system.
> Where I've worked email has simply been a very poor chat which I could not distinguish "info broadcasts" from "the server is down" without getting all notifications or none
Something like Procmail could provide such feature.
Slack (and Discord) is on the long term worse than e-mail/IRC because it isn't federated, nor an open protocol, nor FOSS. This means people are forced into a proprietary, centralized theme park of clients and servers. Its a potential security hazard to put sensitive data in such software.
Of course, Slack (and Discord) both have their set of advantages as well. The good news is, its a matter of time before FOSS alternatives catch up and become good enough.
The advent of proprietary communication tools isn't really something I like, be that slack or discord or other services.
Something tells me that in 10 years neither service will be hip enough to warrant extensive support. If they were to hold relevant business critical information, it would need to be archived but will probably just end up being lost.
That is at least a difference to mail. Also external contacts could be invited to the appropriate channels, but I don't really see much engagement from these users if that actually does happen.
I've already replaced email with Slack. It's not hard, email is really bad. That said, Slack is sorely lacking here, especially with threads. Slack "threads" are an awful experience, with replies generally ignored, so people don't use them. All I'd need is for Slack to treat threads like a real first class citizens, with a view like HN or Reddit, and I'd be a happy camper.
Threads as first class citizens is something that Zulip [0] focuses on, which makes it much easier to have multiple conversations within the same space. It also makes it easier to ignore any conversations you don't care about.
This avoids the problem with Slack where some people might use the threading features, while others ignore it. Personally I'm a huge fan of Zulip, having used HipChat, Slack, Mattermost, Skype for Business, and Discord in the past.
I just wish the client wasn't so bad. I can't believe that if I send a message and I'm not connected at that precise instant that it catn't store and forward the message when I do get connected. In fact, I can't look at any of my slack messages at all.
Every other IM client, email, basically every communications medium since about 1998 has been able to do this, but apparently not Slack.
Big problem I've seen is behavior in using Some vs email, and the monitoring capabilities managers have in monitoring either. From my observations, people use Slack very casually in the sense that they use it like they would any IM platform to socialize/gossip/vent on a whim while at work, not expecting that management has access to viewing each and every thread. This has lead to management playing favorites/politics. In the case of a friend who got a promotion to management at their employers recently, they had to see many of their teammates pre promotion get fired due to those teammates venting on Slack about inefficiencies/incompetencies in management, and management having read each and every response without those teammates realizing they had access.
Email still presents this issue, but not at this level of casual use/expectation of access by management
I worked for a corporation with a 13- to 14-hour time difference. Also, the language barrier was significant. When we sent an email, it had to be translated to Japanese, then the reply often translated back. Slack (or any IM medium) was 100% worthless for this. It has its place, but it is not a cure-all.
Something that I can't seem to find highlighted ever in any discussion about communication tools (but I acknowledge it was kind of hinted at by the federated nature of email in this post) is that by using email you have ultimate and complete control over the information received. I mean in slack you don't have much chance to download an archive of your messages, mentions and message threads (although it might be possible,IDK). On the other hand hosting your own email server (or even by using most of the popular email providers) you have this option out of the box. And this is more important then you think. In court for example this might be the decisive factor in your favour (e.g. having something vs having nothing). But it might be useful in other disputes too, not only in legal cases.
Slack will never replace email as long as it doesn't have end to end encryption, a feature Slack has indicated it is not going to deliver anytime soon due to the "priorities of paying customers".
Personally I hate Slack as it provides too many distractions. Recently I have starting closing down Slack and only allow myself to check it every half an hour to improve my attention span and concentration. Slack seems to be a great tool for product and project managers, however, less so for developers.
It would be great if Slack would allow me to selectively mute certain channels.For example, the lunch-club channel is only relevant when I am actually onsite, however, I always want to be kept up to date on critical production issues.
The Lindy effect is a theory that the future life expectancy of some non-perishable things like a technology or an idea is proportional to their current age, so that every additional period of survival implies a longer remaining life expectancy. Where the Lindy effect applies, mortality rate _decreases_ with time.
I'm using slack in my office (We also use trello for checklist but Slack for communication)
And I do think it'ss a bad decision for Slack to get into the email world.
It will open a door for security breaches and in my company we have some pretty important content on Slack
I also don't want EVERYTHING to be in one place
I like the Slack as it is now, Adding emails to slack aswell will make it a really large platform.
My company dropped slack for Microsoft Teams since it is basically free (bundled in the office 365 subscription).
Email still rocks all of our inter-branch communications and teams is better. The only advantage that Slack has over teams is that it works on GNU/Linux...
The longer I use slack, the more unusable it is. People keep creating small groups with requests. Once you read a message it is almost impossible to find unless you remember everyone that was selected to be in the group.
I agree with the points about the culture problems that are communication medium agnostic. But the solution that the author of this article suggests is Spike, their product. I looked at Spike and while I got the gist of what Spike is for I did not get how does it work. Does it replace G Suite for example? Is it an email hosting? Or is it a complimentary app for G Suite/O365 users? How does it integrate? How does it look like when a person not using Spike receives and email send via Spike? Do they know it comes from Spike?
that's the point that the writer made - Spike can work with anyone (unlike other apps like Slack, Teams, Skype, etc.) Spike works with your regular email, like Gsuite and turns your emails into a chat conversation. The other person doesn't know you're using Spike - they see a regular email. You can even create a channel and message with people not on Spike. That's pretty cool stuff IMO
I'm relatively bearish on Slack, but who knows what will happen in 5 years. Anecdotally I find a lot of people (myself included) have long shifted from "Slack is the greatest thing ever (e.g. 2015/2016)" to "Slack is more annoying than email." At the same time, I don't feel like there's been much new outside of changing the design of their homepage every 3-4 months (can someone explain why it makes sense to throw design/eng resources on this?) and search is still terrible.
I don't think Slack could universally replace email, but it could for some teams (ubiquitous addresses aside).
One of the teams I work with communicate solely through Slack (and do use it asynchronously). All the other teams use some combination of email and Slack, and it wouldn't surprise me if there were teams out there avoiding Slack altogether.
It's just another tool. The usage depends entirely on the audience.
You can also eschew all electronic communication and do things purely in person—that works too. The valuable question to answer here is how well do these processes work compared to each other.
The article talks about a few great features of e-mail that I totally agree with: open standards, portability, asynchronicity. While asynchronicity is achievable with Slack ,I get the feeling that if all of your colleagues are on synchronous mode and you're the odd one out, it'll create problems in the company as you can be labeled a slacker (heh!).
Slack has replaced 99% of internal emails in our organisation. When pointing towards other platforms for long lived content, email just doesn’t seem to have a use case. We still need it for external comms obviously.
The only thing that can replace email is a better email. If we had a version of IMAP that worked with labels (download a message once regardless of how it's tagged) + push, email would be usable again. Currently this is only possible with IMAP with all its flaws OR by giving all your email to a third party to serve through an API designed for modern email. There are perverse incentives preventing this from occurring in any widespread fashion, which is allowing Slack to flourish on the dysfunction of the current communication ecosystem. If we do have a replacement for email, it's not gonna be from a for-profit entity.
Anyway, real-time communications are inherently a different beast from async communications—one is a highly searchable and taggable data store where you're expected to carefully read and type and form workflows around, and the other is for essentially war rooms for collaborative real-time work. Pitching slack as a replacement for email seems like a fundamental misunderstanding of the product.
