Slack will never replace email
medium.com
medium.com
From the HN guidelines[0]
> Be kind. Don't be snarky. Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
If you agree, the upvote button should be enough
up and down work pretty well once focus is in the historical messages window rather than the edit window
this is on the current mac client
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.
More here: https://marcozehe.wordpress.com/2016/01/16/status-of-the-acc...
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!
(edit: formatting, newlines added)
lol.
I really miss being able to communicate via a light-weight, open-source, multi-protocol IM client.
Honestly, Matrix/Riot are becoming more appealing with each release, and support federated clients.
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.
I used to use Pidgin to connect to several communication networks via a common UI, even with the promise of having a single contact list:
I just realized that Pidgin may have a community-maintained Slack plugin!
https://developer.pidgin.im/wiki/ThirdPartyPlugins
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.
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.
So you could use alternative clients will a full suite of accessibility features.
But now they're gone.
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.
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
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.
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.
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.
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.
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.
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.
It's even stricter if you take any type of public funding - and I'm pretty sure it's an EU-wide directive.
Some “friends”.
Additionally, I am a tech person, and not a lawyer. Sueing my employer to allow me to work productively doesn't feel like nice way to spend my time.
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.
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?
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.
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.
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?
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 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.
And of course, it's all documented here: https://get.slack.help/hc/en-us/articles/115003340723-Keyboa...
It's not perfect but it also doesn't seem impossible to me. Here's the gif: https://d1sz9tkli0lfjq.cloudfront.net/items/3y1j1Q1G1p033z06...
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.
- 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.
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)"
> If you abused the urgency, we had a way to track that, and let you know.
So how is Slack different? You can still track the urgency and let the person know -- it is right there in the message.
And if they really don't understand that @here is bad, then you can always disable @here on per-channel basis (I have this on a few channels, in fact)
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.
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 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.
Ain't no free lunch, and don't be suckered into doing free work.
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
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>
Why would you want to be interrupted by inane chatter when you're working?
I worry that people are trying fix org culture problems with communication software, which is unlikely to succeed.
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.
Hmm. Might be true for you.
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.
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.
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.
If people keep doing that repeatedly even after being told then you probably have bigger problems in the company than the messaging app of choice. You can also just disable it: https://get.slack.help/hc/en-us/articles/115004855143-Set-wh...
> People ping each other asking questions instead of reading docs.
That's not a Slack problem, it always existed on IRC, people tapping you on the shoulder in the office or on mailing lists and forums.
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)
I think that notifications is a productivity killer in general - no matter the software behind it.
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.
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.
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.
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.
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.
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.
[0] http://zulip.org
Every other IM client, email, basically every communications medium since about 1998 has been able to do this, but apparently not Slack.
Email still presents this issue, but not at this level of casual use/expectation of access by management
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.
I got this from https://news.ycombinator.com/item?id=17374500 but there have been other benefactors: https://hn.algolia.com/?query=shift%2Besc%20read&sort=byDate...
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.
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.
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 search is practically useless.
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.
- Company or department wide announcements
- Welcoming new hires
- Artifacts from build systems and automated tools
- Inter-team communications when planning something new
Anything with a real deadline is communicated through slack or skype.
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.