Live data from Hacker News

Curing Our Slack Addiction

blog.agilebits.com

141–150 of 187 posts

Re: Curing Our Slack Addiction

#141
post #93

Earlier quoted context omitted.

I have a hard time agreeing that "Slack's a far sight better than email." The lack of threading and context (mentioned in AB's writeup) means you have to maintain a lot of state (and keep up to date) in order to get any value. That defeats the point of having automation! For good or ill, the 40+ year history of mail means there are various tools and conventions that allow your computer to do part of the work for you.

Also, email is an open standard, with plenty of choices in both client and server software. Slack is a proprietary system. Why are we actively axing solid, widely distributed, open ecosystems for proprietary ones? It'd be like if everyone woke up one day and decide "eh, Linux is just not animated-giphy enough, let's all switch to this startup OS with a crippled free version."

Because Slack doesn't have to write up an RFC and wait months/years for feedback before getting features implemented. People care about features, not interoperability (until they want out, at which point they feel the lock-in burn).

Re: Curing Our Slack Addiction

#142

Earlier quoted context omitted.

For the first, IRC has a solution for that, too. 1. SASL auth – some servers even support Oauth via SASL, or certificate login. 2. That’s what Quassel and IRCCloud provide as a one-click solution. 3. With everyone using Quassel or IRCCloud, this also becomes easy. 4. There are many services that provide webhook -> IRC services ;) As someone who has been using Quassel, where everyone else uses Quassel, and who uses SA…

And packaging. Just picking on one of the ones you've suggested: Quassel is an app, so I can't easily try it out. I certainly can't invite everyone in my company to use it by clicking a single link in an e-mail. It doesn't have an iPhone app, I think those are quite popular. And so on. Seriously, all these things are pretty easy, as evidenced by the fact they've been working since the 80's in the form of IRC. The val…

Interestingly, that's exactly what I personally am working on: mobile clients for Quassel, easy deployment (single docket container for everything), quassel-as-a-service for people to just invite others, etc.

A web app also exists, but the discoveravility is an issue.

Packing the things up properly, marketing them well, etc is easier, as we also have the advantage of being open source, which helps in open source communities.

Re: Curing Our Slack Addiction

#143

Earlier quoted context omitted.

For the first, IRC has a solution for that, too. 1. SASL auth – some servers even support Oauth via SASL, or certificate login. 2. That’s what Quassel and IRCCloud provide as a one-click solution. 3. With everyone using Quassel or IRCCloud, this also becomes easy. 4. There are many services that provide webhook -> IRC services ;) As someone who has been using Quassel, where everyone else uses Quassel, and who uses SA…

And packaging. Just picking on one of the ones you've suggested: Quassel is an app, so I can't easily try it out. I certainly can't invite everyone in my company to use it by clicking a single link in an e-mail. It doesn't have an iPhone app, I think those are quite popular. And so on. Seriously, all these things are pretty easy, as evidenced by the fact they've been working since the 80's in the form of IRC. The val…

[deleted]

Re: Curing Our Slack Addiction

#144
post #95

I was previously working in a company that used Flowdock[0]. Current place uses Slack and I've noticed that there are multiple things bothering me. Biggest complain for me is that the Slack UI gives too much weight on the fact that someone has talked on a channel. This makes me feel like I should be reading that, even though it might not have anything to do with me. This creates a whack-a-mole situation where I end u…

I also like that Flowdock splits into two panes, with one pane for notifications about things like Pivotal Tracker, Github commits, etc. It was a better way to separate noisy but occasionally useful notifications from the more important conversations than having separate channels. I wish Slack would implement something like this (separate pane for "Bot" users).

Re: Curing Our Slack Addiction

#145

I really do not get this hype around Slack. Chat, group chat, video conferencing are nothing special. These applications are commodities and included with so many other apps. Eg. if you use Google Apps/Mail you get the fantastic Hangout for free, working on all devices. Moreover, every time I login Slack it feels so crowded. If you want to change something you have to navigate through a forest of settings here and th…

Slack is IRC with history. That's it. If IRC had history built in, Slack would never exist.

Re: Curing Our Slack Addiction

#146

Earlier quoted context omitted.

IRC is a protocol, it has nothing to do with UX... You can tack IRC on top of a pretty client and you can get pretty similar results I'd assume. DISCLAIMER: I never used Slack.

UX != UI Simple example: with Slack (or another hosted, web-based chat app), I can invite the non-technical head of sales to join it via e-mail, and they can. They literally cannot install an IRC client. I can get similar results, but "I" isn't enough for a communication tool to be useful.

Why can't you do it through the web interface of a company-backed IRC network? There's literally no difference there, IRC is just a protocol, you can still wrap around your own local stack with registration, email notification, fancy UI (I know UI != UX) and auto-invite system or whatnot.

I just don't get it...

Re: Curing Our Slack Addiction

#148
Why has SMTP evolved in all those years?

Email could handle much more automation, and be friendlier to on-demand inclusion in discussion threads, but AFAIK, it doesn't support a standard way to provide:

1. End-user controlled behaviour.

2. Whole-thread forwarding initiated by the end-user.

#1 would require a way to allow stantard plugins to be written, either by sysadmin or end-users. (Obviously, the capability and authorization of each would be different. End-user ones would only be allowed to touch end-user own emails.)

#2 would allow easier evolution of email threads.

I'm not talking about proprietary extensions to a particular SMTP implementation. I'm talking a standardized protocol addition to support these scenarios.

Am I missing something? Were changes to SMTP ever attempted?

Re: Curing Our Slack Addiction

#149
post #133
post #29

Here's my best practices list: 1. The best use of slack is the free edition which has limited history. Once this lack of history is made clear, people use it simply for online pings. Since notes, files and everything will disappear, people will automatically put the effort to put those things in the right tools (wiki, bug tracker etc). 2. Don't expect people to be online. It's the same as irc. If people are there, th…

"Integrations.. are a gimmick" I disagree, some are. Giphy, though a pleasure to have on the team is a gimmick. Hubot is an essential member of the team. Our company is deploying pretty much all day, and the integration of our deployment system with the bot scripts make things so much easier.

> Giphy, though a pleasure to have on the team

I couldn't disagree more. I hate giphy integrations, and I disable them in any room I have any control in.

It becomes abused far too easily, and the results are so rarely relevant. "/giphy high five" will return a gif of someone high-fiving 30% of the time, and will return nonsense garbage the rest of the time, prompting people to try, try again, flooding the room with animated images of celebrities, minions, or whatever other garbage someone has uploaded and tagged poorly.

And that's not counting the one jackass who just gets bored and starts flooding the room with random gifs. (That happens much more rarely in work-dedicated channels, but it makes off-topic rooms a chore.)

100% gimmick, 0% pleasure.

Re: Curing Our Slack Addiction

#150

Why has SMTP evolved in all those years? Email could handle much more automation, and be friendlier to on-demand inclusion in discussion threads, but AFAIK, it doesn't support a standard way to provide: 1. End-user controlled behaviour. 2. Whole-thread forwarding initiated by the end-user. #1 would require a way to allow stantard plugins to be written, either by sysadmin or end-users. (Obviously, the capability and a…

You can forward a whole thread. That's client-side behavior. The simple way is to select the thread, encapsulate it as an attachment of type RFC822/email, and send it off.

The complicated but more user-friendly way is to reconstruct the messages into a single non-repeating conversation view and send that.

In either case, SMTP doesn't need to change, and you don't even need support on the receiving client, just the sender.

Post reply on HN