Keep in mind that this project was a lark that Nicki (http://www.nickivance.com/) and I literally made in the back of a van for her exact use case.
My article is a fun writeup of the design considerations and challenges of an email-only UI. It's not supposed to be a marketing piece, to convince you to (not) use the service, or to pass moral judgment on anyone's preferred communication medium.
I should also point out that emailing the app a Slack token is the same as emailing it a password, since the token allows it to read/write messages on your behalf (which is, of course, the whole point). Sending passwords around via email has security implications, which I'm sure you (a thoughtful, attractive, and considerate HN reader) can come to your own conclusions about based on your personal needs and risk preferences.
on the stop slacking site, I think the "captions" should appear before the images. It was initially confusing because the first caption doesn't show under 800px height screen. If I hit spacebar and scroll a page, then I see "you get mentioned on slack" and the following picture that looks like an email client, which is confusing.
There are just so few instances where synchronous group communication (like Slack) makes sense in a workplace. If you need to talk to a large group of people about a project, it'll be more efficient to (gasp) have a meeting. Recording/itemizing data in a slack channel is horrible and basically unsearchable after a few days.
The nature of slack forces people to always "watch" for pings and channel updates, lest they get labeled a slacker for not responding. It's a 24-hour long meeting with no agenda, no guidelines, no leadership, and the occasional guy who jumps into the room with a bad joke.
Slack, like all text messaging is an asynchronous messaging tool. Of course it's horrible using it synchronously the way you describe but that's not the way it's meant to be used or is used in my company. I often miss direct mentions on slack because its mobile notifications are almost non-existent or because I'm working on something else. Someone who is too stupid to understand the nature of asynchronous communication and calls out people for not responding right away is an idiot and an asshole whether it's a manager at work or a so called "friend" (no one who makes synchronous demands on one's time to text chat can be called a friend). Slack used properly is about as far from a synchronous meeting as you can imagine. A boss that demands constant synchronous slack communication is a sign to look for a new job.
If you're using Slack in a structured environment (such as a company), then you can impose structure through policy, rather than technologically.
Specifically, if you want to avoid a "24-hour long meeting", then why not just have an actual meeting, in Slack? Run it like an actual meeting, just with typing instead of voice/video chat.
If you have actual, structured meetings via Slack, then you get all the benefits of everything going through text (a canonical log anyone can reference; nobody having to repeat themselves; no having to fight to get everyone on the call; people being able to "speak" (i.e. type) at the same time without talking over one-another; etc.), while also getting all the benefits of Actual Meetings (people trying to make efficient use of their time so they can get back to doing something else; someone "running" the meeting and passing a baton for who is expected to be speaking at any moment; etc.)
If you do that, then the rest of the time, Slack is just a virtual water-cooler (and a convenient built-in IM system for talking to people who aren't in your office.)
Text is far slower and lacks all the non-verbal cues we use in person or even over video chat. There's almost no upside to having an actual meeting in Slack other than a text log.
Did you mean: text allows you to take your time and revise what you're going to say before saying it, and makes it impossible for aggressive team-members to "cut off" less confident team-members?
> lacks all the non-verbal cues
Did you mean: text is accessible to people on the autistic spectrum, people with social anxiety, people with verbal tics, and anyone else who avoids jobs entirely on the basis that they'll have to talk to people, or who might be disadvantaged by others' prejudices based on their "non-verbal cues"?
Also, to specifically highlight:
> in person
We're presumably talking about a remote-only workplace here. There is no such thing as an "in-person" meeting—or, indeed, a synchronous meeting—if your team is spread across the complete gamut of time zones.
When I worked at IBM, we were switching from IM and live video-conference meetings, to entirely Slack-based communication. It was for exactly the reasons I stated above.
The most important of all those reasons, though, in IBM's case, was that it was:
> a text log
...because now you can employ deaf people! (Or people with sensory or executive impairments that get in the way of parsing speech in realtime.)
I can assure you that passing along a quick note about a task or process in a Slack channel, which respective members can check on at their own leisure, is _far_ more efficient and time/money cost-effective than calling the 40 people (perhaps spread across multiple buildings, cities or countries) into a meeting to discuss that same minor detail.
How is that better than email? If you want people to check it at their own pace (async), then use an async method. Slack expects everyone to check it constantly. At least in my experience :(
Being able to bring someone into a discussion which they can quickly respond to (or browse back on later) is way smoother a process than having to send another "adding Bill to the thread" Reply-All every time you want to add someone.
Not to mention the integrated file attachment (inline screenshots/video, anyone?) and impromptu /call feature to trigger a voice call or screen share.. there isn't even a reasonable competition there anymore.
If you feel overt pressure from expectation to read/respond immediately, it seems you may need to establish a Slack-usage culture that works for your team (or express that the current expectation level doesn't work for you and is affecting you negatively). For me personally, I don't necessarily expect anyone to respond immediately, even if I "Direct Message" them and they are Online. While I respond to most stuff promptly, it's never a problem if I don't.
> Being able to bring someone into a discussion which they can quickly respond to (or browse back on later) is way smoother a process than having to send another "adding Bill to the thread" Reply-All every time you want to add someone.
That could be solved by using NNTP instead of email. Plus, with clients that handle proper message threading and search, you can get something far better than what Slack offers in terms of going through a discussion that has already taken place after the fact.
I agree with most of what you're saying here, but this didn't resonate with my experience:
> basically unsearchable after a few days
Recently, a coworker asked me for more context about a pull request I had authored 14 months ago. Within minutes I was able to search Slack for relevant discussions, stakeholders, and reasoning.
I left a message in a channel 20 days ago, but I didn't remember the exact content. I had to skip back in the channel (took a while, slack paginates and there was a lot of content), and then I had to mouse-drag to even highlight the text to copy. Incredibly inefficient. I need a chat bot to record our messages the same way we used irc bots!
If you're a Slack admin, you can export a dump of the chat history. Such dumps are nominally for import into another group-chat system, but—given that the dump is just a tarball of newline-delimited JSON events, one file per channel—it's very easy to parse through in pretty much any language.
And, of course, if you have a public Slack community, there's nothing stopping you from taking regular dumps and baking them into one-per-day HTML pages, and then putting the HTML files up somewhere where Google can find and index them...
> there's nothing stopping you from taking regular dumps and baking them into one-per-day HTML pages, and then putting the HTML files up somewhere where Google can find and index them...
Is there a reason why Slack doesn't just have a setting that enables logging to a local file on disk?
wee-slack gives you a minimal terminal based slack client within weechat and mosh handles ssh connections over low bandwidth, high latency connections.
Using this set up I’ve been able to reply to messages at times a ping to 8.8.8.8 resulted in >90% package loss.
Nice, you've got a great option for low bandwidth. With lots of functionality!
Your project name wins a lot of points with me.
We wanted Stop Slacking in email for two reasons beyond bandwidth:
+ I find group chat distracting
+ I already need to use email (as a freelancer with multiple clients) so this streamlined comms into one medium
Just a question, since you appear to be using email as your primary communication medium, what software/workflows do you use? On my side I always use Slack, and while I understand its drawbacks it seems to be the best for me so curious to know about other approaches.
That's a big question. I mainly use email as one of my todo lists. I get notifications from tools like Jira, Trello, and Basecamp, depending on my client. Basecamp introduced me to reply-by-email notifications. :)
The experience of a Slack workspace varies greatly between teams. Slack itself is just a tool. If it works for you, keep rolling with it.
Slack is going the platform route. They have a huge amount to lose disabling API access. Add-ons and interconnectivity are what make Slack so popular. Without all the integration Slack becomes much less attractive.
Other big social networks have a very different business model. Because they ask users to pay directly for the service, as opposed to ads on UI, using Slack via API or UI shouldn't really matter to them.
yes, you're right. However, the slack RTM API can still support IRC clients (with a little more work - need to setup the IRC server, like [1]). The API is like a superset that way.
Great write-up, however I have concerns over the security of this product, especially the part where they submit a Slack token directly over email.
Email itself is not secure, but at the very least an attacker intercepting a single message will only get the content of that message. An attacker intercepting the token will however gain persistent, remote access to all their current & future Slack messages with no way for the user to even know they've been compromised.
Personally I prefer slack over email. I basically don't read emails anymore and just mass delete them once a month. I get so many auto generated ones I barely even check.
The quality of email has such a low signal to noise it is becoming a waste of time to even check.
Off topic but related to communication. I wish voicemail could be an opt out thing, I haven't listened to a message in a decade.
Auto-generated emails are not the fault of email itself. Just avoid signing up for shit and if you need to sign up then take 5 minutes to visit your account settings on that platform and uncheck any notifications/spam-letters you don't care about.
I personally have only one or two auto-generated emails a week, at most, and all of those actually require my attention (expired credit card, etc). The other ones are either disabled or filtered away at the server level before they even reach my client (thanks to rules in Office 365).
> I wish voicemail could be an opt out thing, I haven't listened to a message in a decade.
Set your outgoing message to state that you never check them and that people should @ you on Slack instead.
> I get so many auto generated ones I barely even check.
That's not emails fault, that's your fault for not using the tool properly. All clients have filtering and blocking options. If you don't want the mails, tell the sender to stop sending them.
You usually can turn it off I think. One of my colleagues' greeting states that you should _not_ leave a message, followed by 2 minutes of silence, to put off all but the most committed.
(Or maybe it's the way that people use #Slack. Which isn't strictly Slack's fault, but still, ...)
I sort of miss when we would have internal WG-specific mailing lists, which were archived, web-available and searchable. Anyone could join (almost) any group they wanted. It was threaded (of course), and people tended to write longer more complete responses (with no reaction emoji!).
Don't get me wrong - I love slack for the CI/CD stuff, and as a monitoring dashboard for all sorts of alerts that various parts of the various teams might be interested in, but it doesn't really replace the use-cases that email is actually pretty good at (in my opinion).
The idea that slack should replace email was always a laughable one. It's just another communication channel - people who had let their email become an unmanageable mess needed a new app that wasn't a mess yet. Now people are realizing that slack can be just as much of a mess if you let it get out of control.
Both slack and email are awesome and horrible in their own way. The same goes for IM, WhatsApp, Intercom etc etc. Most productivity is actually lost by cross channel communication.
As mentioned in the article "... that company communicated almost entirely via Slack" So where do I digg up the rest? It might be in a voicemail of a colleague.
If slack would implement a push-IMAP api. I could at least drop one app :)
I don't see anything wrong with the majority of asynchornous communication methods. Mind you, I'm a fan of slack and a lot of people aren't. The issue though, I think, and the reason why slack is so widely used despite the fact that most users tend not to like it is because of the UI. It's friendly and easy, for surface level tasks, and that's far more important to people than the fact that it's synchronous (based off of my own experience, can't cite any stats so I'm not making a claim here). Email could very well work for this, and several apps have tried to "IM-ify" email, but none have really caught on. It's a UI and UX issue fundamentally, not a capability issue, once again according to my experience.
Reminded me of Stallman's approach a little :D (I fully get why this would be necessary with slack, low bandwidth hotel/train wifi etc make the desktop app basically unusable here in the UK whilst travelling). https://stallman.org/stallman-computing.html
This was a cool project - I'm impressed. Just wanted to point out that http://topicbox.com offers similar functionality. Topicbox won't interface with Slack but rather replaces it. Run by the folks who do Fastmail, it's a modification/upgrade of old mailing list functionality. If you can get your team to use it, you can do most of what you did with Slack over an email interface that also offers perpetual archiving. I checked it out as a solution for archiving important project emails late-arrival employees would need to read to understand a project. Topicbox and this are slightly different, but both solve the high-bandwidth/low-availability problem in a way.
These products that require always-on internet connectivity on robust connections really tire me out.
Thanks for sharing Topicbox, that hadn't come across my radar. I've been pleased with Fastmail.
I can see why it would be helpful for onboarding employees. That's an important use case. Having jumped on multiple teams mid-project, it's tough trying to review a Slack channel history to get context.
The best slack interface I've found is appearing online with the tab closed. It's the best of both worlds: no distraction while appearing available. If someone messages you and you don't respond right away, they'll assume you are tending to more important matters.
Imagine, there's an app with Slack's functionality that already has such interop with email as you've built here :) Fleep: https://fleep.io/
Anyone who does not want the group chat experience can be included in conversations via email.
Currently, that does mean getting all messages via email, and not @mentions (nice idea, worth considering for Fleep's product team). But idea is similar:
Full disclosure: I do work at marketing in Fleep :)
I have always wanted to create a Slack alternative that is built upon email. Everything happens on emails (and hidden headers), standards-compliant since day 1 and low barrier to use.
* Is the client IMAP? Are there any protocols that would be required on top of it? Would there be an advantage to a separate client?
* Are the contents encrypted? Will it work with other encryption strategies in other clients? How will you share the keys? If it's not encrypted, how will you share anything that cannot be public?
* How do you handle who is allowed to use and who isn't? When someone is stripped of access, what happens? Does that restrict it to business applications where someone controls the email account?
* How does a new individual to the chat acquire the history of the conversation? Is there some sort of mail API behind the scenes?
I'm sure it's possible but I think you'd end up with a separate server and client solution and the protocol wouldn't end up making much of a difference, mostly because of encryption requirements.
This is neat. Have you seen any issues with using legacy tokens instead of normal OAuth? I made an extension[1] for using Slack inside VS Code during pair programming sessions - and it doesn't seem to work for enterprise users with legacy tokens.
> "...interact via email with the poor souls trapped in the endless, no-agenda meeting that is Slack."
Most of us agree that email __as a collaboration tool__ sucks.
Slack has its (growing?) contingency of haters and dismissers.
But there's so something common to both:
- Us
- Work
Perhaps it's time to come to terms with the fact that while work has its place - in the context of modern culture / society - we humans just aren't wired for such work.
Tool after tool tries to solve "the problem" but time and again they "fail." As if the sky being blue is a failure.
Keep in mind that this project was a lark that Nicki (http://www.nickivance.com/) and I literally made in the back of a van for her exact use case.
My article is a fun writeup of the design considerations and challenges of an email-only UI. It's not supposed to be a marketing piece, to convince you to (not) use the service, or to pass moral judgment on anyone's preferred communication medium.
I should also point out that emailing the app a Slack token is the same as emailing it a password, since the token allows it to read/write messages on your behalf (which is, of course, the whole point). Sending passwords around via email has security implications, which I'm sure you (a thoughtful, attractive, and considerate HN reader) can come to your own conclusions about based on your personal needs and risk preferences.