Designing an email-only Slack interface

Please just ask for that token and email over SSL. It's that simple. No need to risk people to lower user acquisition ramp.

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.

Hey, instead of polling, for the trigger words such as @mention etc you can use outgoing webhooks integration.

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.)

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.

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.

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

Thanks for sharing wee-slack!

It is because of projects like these that I hope Slack won't disable API access the way other big social network companies are doing.

Totally agree. The intent may be for good but this is the textbook example of "how not to acquire sensitive information".

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.

If so, it needs to do a better job.

(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).

Well, I doubt you can ever replace email with a centralized proprietary system.

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.

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.

I often feel that what is horrible with email is the ui.

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.

This looks perfect!

Here are some clarifying questions:

* 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 might be a nice alternatives for open source work if it would tie into a email archive system as well.

And its open source. Thanks for the share.