Hacker News new | past | comments | ask | show | jobs | submit login

I wonder if the outcome would have been different if Slack was incorporated outside of the US where Microsoft could use some of its non domiciled cash on the acquisition?

http://www.ibtimes.com/microsoft-admits-keeping-92-billion-o...

Also interesting to think that Slack could be worth so much. Look at ICQ, Microsoft instant messenger, etc.

It seems as though slack like tools get eclipsed every 5-10 years as a new generation comes along with a new favorite tool.

I'd be interested in hearing from someone who would argue that slack will be a dominate communication tool in 5-8 years time and still exist in a meaningful way in 10 years time.




Frankly Slack's success is the utter failure of every alternative on the UX side. MSN messenger was perhaps wrong-footed by the shift to multi-device, but none of the other tools have such an excuse. It's not a generational thing, it's an incredible level of, there's no other word, incompetence on the part of the makers of major messaging software (Skype in particular).


MSN had big flashing ads. When I first saw that I assumed I was dealing with another windows install with malware on it. I've paid for the OS, why have I got this freemium crap?

Slack has no way of letting me know who's read the messages. Come on, it's 2016. I asked them about this and they told me the only solution is it get each contact to add a sunglasses icon as they read each message! What a joke.


What does 'read' in a Slack context mean, though? If you scroll past it quickly, is it read? If you accidentally open your Slack window, is it read? A 'read' notification would just be a misleading user experience.


Read in the way a Facebook messenger message or a hangout message is read; you've got the "channel" open and the message is visible or is above the visible one. Clearly it's impossible to know whether a message has actually been read by a human but there Facebook/hangouts solution is almost perfect.


It's not visibility, it's focus (at least on desktop). If you don't click a messenger box, it will display the message but not acknowledge it as read (on the desktop client, on mobile it works based on whether the message is displayed while the app is open).


I think that's the right thing to do from a privacy standpoint. I don't want people to be able to tell whether I've read their messages to me.


Yeah I agree, I think people routinely underestimate the level of quality and amount of time you have to put into a consumer product.

A good example is Yahoo Mail... this product is used by so many people, and was supposedly overhauled a few years ago, yet it is mediocre in so many ways.


What email product isn't mediocre? This entire vertical needs an upgrade. Perhaps Email is Hard.


Gmail is good, but it got that good about 10 years ago, and hasn't gotten much better since. (Arguably it's worse in some respects.)

When Gmail came out it was a breath of fresh air... now it's just the bar you need to meet. It's sad that Yahoo hasn't been able to meet that bar in 10 years.


Fastmail!


100%


> It seems as though slack like tools get eclipsed every 5-10 years as a new generation comes along with a new favorite tool.

You've definitely got a point there. Although I do want to mention that part of the reason Slack eclipsed other tools was, in part, its Websocket based protocol. They have created a fairly complete unified messaging application because of it (IMO).

They were the first movers in the area. I don't know if I would provide much of a meaningful discussion regarding the longer term viability of Slack, but I think they have a chance to be meaningful, maybe even dominate in 10 years time.

They are already Websocket based and they are moving towards WebRTC support...if they take that direction and add P2P support to provide truly secure encrypted communications where certificates are negotiated P2P, then I think they will explode to even greater heights than they have already achieved. Of course, this is not a simple task, but the business implications of truly secure communications channels would be compelling for most corporate enterprises.

Now this is not the same as 100% secure endpoints, but it would be a massive step in the right direction.

Edit: Forgot to add P2P link... https://developer.mozilla.org/en-US/docs/Web/Guide/API/WebRT...


I don't know why Slack is seen as a first mover; Hipchat, Flowdock, etc all existed beforehand. Slack seems to have raced ahead by ramping up marketing and not just focussing on B2B sales.

In terms of tech I actually see Slack as behind in the default product (no threaded conversations >_<), but maybe the ecosystem they're trying to foster will actually be useful or maybe the money they've spent on marketing will be irrelevant and they will collapse due to overfunding.


IRC Cloud's web client uses WebSockets.


I don't think that IRC Cloud was originally based on websocket...I think it used 'keep-alive' but I could be wrong. Although it still has documentation on how to use HTTPS for stream end-points (https://github.com/irccloud/irccloud-tools/wiki/API-Overview).

Also can't find much information about WebRTC support for IRC Cloud.


What did web socket have to do with their rise?

They won't support p2p encryption because server side search wouldn't be possible.


10 Years? Hmmm... That is a <i>very<i> long time.


Network externalities are powerful things. Especially when it comes to enterprise level applications.


> ICQ, Microsoft instant messenger ... slack like tools...

I think people too often overlook Slack's integrations. Yes, Slack is "just" chat or "just" a glorified IRC. Or is it?

I don't know how long it would take me to integrate my Stripe, Github, Trello, and Zendesk streams into IRC to the point where I could set it and forget it. I think for business users at least, using this type of setup _effectively_ could make it hard to move away.


Does a tool display clickable hyperlinks? That's all the integration I (and I suspect many other people) care about.

I can't even imagine what it might mean for " Stripe, Github, Trello, and Zendesk streams" to be integrated into Slack, or why I might want them to be.

Want to share a gist with somebody? Just send a link to the gist to the chat channel, and people can click it.


So a lot of times, on a project, maybe right after a production deploy, I'll just keep the production logs open on a spare monitor or a TV, and passively keep an eye on what's going on while working on other things. I'm not looking for anything specific: my intuition just kinda kicks in if something seems amiss. Suddenly jumped from a few errors a minute to a continual stream of backtraces? The logs stopped streaming entirely? I know it when I see it. Kinda like Cypher watching The Matrix.

Now, if I had to tab between panes across 2, 3, 6 app servers, background workers, and database instances, I just wouldn't bother. It's only useful as background noise. But that's fine, because there are tools that let me easily consolidate all of my logs into one stream.

And that's how I see Slack. Just like I can't get a notification every time I have one exception happen in production, because it would kill my workflow, I can't get a notification every time somebody updates a Trello card or resolves a Zendesk ticket. But what I /can/ do is passively watch the stream: Slack is the consolidated logfile, not for my production servers, but for my company.

Could I configure all that with IRC? Yes. Do I want to set it all up, when Slack lets me OAuth against every single service imaginable with one click? No, I really don't. My time is far more productively spent elsewhere.


Search is also a major feature.

For integrations, Github tells us when there's a PR. Yes, there's a clickable hyperlink, but I also get to know a bit more inline. It's additional context you don't get with only a hyperlink. There's less switching contexts when things are inlined ... it's a UX feature. I'd call it a feed of things happening across all of my apps, mixed with the ability to discuss those things in a standard place.

The integrations also give you shortcuts to actions without switching from your "command" line. Sure there are _some_ tools you can install on your local machine, but none make it this easy. Butterfield had the same success with Flickr (which yahoo subsequently destroyed) in making a killer user experience. That was for photos, Slack is for communication.


I'd say slack/hipchat has become the repository of alerts/notifications/etc that I would normally receive through e-mail. A lot of times these notifications aren't super mission critical and don't require immediate attention, but it's nice to have the history of them so I can investigate when necessary.

Having this outside of e-mail keeps my e-mail inbox less cluttered. That's my reason anyways.


Same, except the only issue (similar to email) is that when I initially check something, the little alert thing disappears. So it can easily fall off my radar if I get distracted. Hence my need to keep my Trello todo list current.


I can't speak for the rest, but I personally use the GitHub integration to be notified in chat when builds have failed, pull requests are submitted and commented on, etc. Otherwise I end up having to keep GitHub open in a tab and refresh every minute.


I don't understand. Why would you have to have a github tab open and refresh? There have always been email notifications for all these events. Also, why is getting these notifications in chat preferred over email?


Chat is just nicer to work with.

Emails are in their own isolated packages. If i get an email saying the build broke, there is no easy way to check the last time it happened. I wouldn't be able to glance at the last few messages and see that the build breaks every time "X" commits or the tests fail every monday. I can't easily get context on what someone was doing when it broke.

With something like slack it's all right there. The last 3 alerts, maybe a few messages from devs quickly explaining what happened (or preemptively saying that the build is going to break, and it's okay), someone taking responsibility and saying that they will handle the fix, etc...

It's just nicer.


I would just create a folder and a mail rule that moves the mail automatically. You would actually be able to filter your mail with more granularity than what a simple Slack channel can provide


When the notification comes into Slack that the build broke, I can immediately type in the chat "I'm looking into that one" and everyone knows what I'm referring to and knows instantly that they don't need to waste time on it.

At my workplace, everyone is usually always active in chat working out problems and having discussions, so a notification is more likely to be seen by more people sooner in the chat than in an email.


Fwiw this is pretty common on IRC too (and has been for a long time). Dev channels pretty often have a bot that's periodically messaging some info on new bugs, build failures, etc. So I think does reflect a common developer desire that even predates Slack.


I prefer having everything in one place possible. Clicking a link means a new tab, and if you have multiple systems, that's a new tab for each system and its links. Gets out of hand quickly.


Slack's core killer feature is a reasonably well executed omni-channel experience. I'm not talking about it as a central hub for comms via integrations (although that flows from this idea), but about seamless handoff creating a unified experience between desktop and mobile (and email/app/desktop notifications). That's interesting because it isn't chat related and could be applied to most applications


Slack seems to have mostly eclipsed Hipchat, at least among Silicon Valley startups, but integrations probably weren't a huge factor in that. Slack does have a nicer flow for integrations, but Hipchat worked quite well (and actually had much-missed features like customizing the background color of messages; it's unfathomable how Slack could still not have this feature).


>it's unfathomable how Slack could still not have this feature

I hear this saying a lot, and every time I just can't take it seriously.

This is the first time I've ever heard of someone wanting customizable background colors for messages on a messaging platform. It's just not something I or anyone I know about cares about.

I just can't see how that would be considered a high importance feature by anyone.


It's all about integrations. We have all sorts of server messages and errors in a couple of our Slack engineering channels. Slack provides almost no way to visually distinguish these messages based on importance. In Hipchat, we had red/yellow/green background colors that worked great.

To be clear, I'm not dead set on having background colors. I just really miss having a good visual distinction between messages.


I came on a little strong there, it's just saying things like "how could they not have [insert niche feature here]?" drives me up a damn wall!

But that makes sense, and it would be a nice to have. In the meantime can you "hack it in" via different icons per status?


We do it with icons. It's still nowhere near as immediately recognizable at a glance, but I suppose it's fine. I just had a thought: you could embed an image preview that's just a solid red square. That would be very noticeable for important errors.


HipChat's colored messages made it easy to see the error messages in a stream of mostly unimportant notifications. Slack kinda lets you do the same thing with a vertical colored bar to the left of the message, but important/error messages are much less visually distinct.


I seem to remember AIM allowing customized fonts and background colors around 15 years ago... Just sayin'


And a Porsche from 1992 can outrun a current day Prius, it doesn't make one better than the other...


Depends on how long the race is :)


And it was a miserable nightmare trying to talk to my friend who would decide to use bright yellow Comic Sans on a bright pink background.


AIM is actually really nice these days. I wish I could get my friends to switch back to it.


mIRC supported ANSI colour codes for foreground and background back in the 90s. I seem to remember people hated you for using them though.


People go ape-shit about silly features in IM clients all the time. Case in point, emoticons


Back when I was a boy we didn't have any fancy emoticons! We used ascii characters and we LIKED it! >:-O


Hipchat, like ALL other Atlassian products are always feeling just incomplete. By design. (I'm using 80% of their product line).

Slack just feels complete. For tech and non-tech teams.


>get eclipsed every 5-10 years as a new generation comes along with a new favorite tool

I wonder if this rule holds just as much for IRC - for most FOSS projects, IRC is the go-to choice, and it's been that way for a long time.


The reason IRC is still king is because it is so damn simple. You can plug literally anything into it as a bot. When I was at Facebook we used IRC extensively for builds, deployments, testing, etc. It is just ridiculously simple to plug any part of your infrastructure into it that using anything else just feels like a waste of time.


Many new FOSS projects are now using Slack instead of IRC, with a variety of methods for auto-inviting members of the public instead of Slack's intent of manually managing users.

Another popular one now is Discord, which is Slack-like but anecdotally better for large sets of users because of a more robust admin/permissions scheme.


I use Discord for gaming (which seems to be their main market?) and it is amazing how nice it is. I wonder if Slack could just buy them and integrate the voice features into Slack, or introduce their own similar functionality. The voice stuff is seriously very nice and something that Slack doesn't do at all.



That's good to hear, I hope it is as streamlined as Discord because it really just works there. It's also free in Discord (although I don't know what their business plan is) and according to that page it'll be part of the Standard plan and above. (group calls, that is) But I understand if they're targeting different audiences (business vs gamers).


Slack bought screenhero and is apparently working on integrating the screen sharing and audio into Slack.


Most FOSS projects I am involved / interested in seems to use http://gitter.im, though a few uses Slack


IRC is my favorite, but IRC is bad for company, because you have to manage your own IRC server (you don't want to host your company stuff on freenode, do you). Also, IRC doesn't come with any integration with third party tools. Unless you have a very willing hacker willing to build the integration from scratch, IRC is bad. Not that you would never find a use case to write custom bot on Slack for your need, but I imagine tools like Jira, Jenkins are already created and are well maintained.


In an enterprise environment, Slack is sometimes considered bad because all of the company data is not under the company's control. I seriously doubt that the company I work for ever would go all in on Slack, precisely for that reason.


A lot of enterprise claim to run their own services, but in reality, they outsource to third party to host them, for example, centurylink for active directory or some vendor for managed exchange servers. Heck, a lot of companies bought 365 and Box. People use Skype for communication, passwords are being thrown all over emails and chats. Code are on GitHub. While there is auditing in place, the reality is, a lot of enterprise data aren't really controlled and stored on-premise servers, and auditor cares mostly whether access are limited, logs are available for tractability, and whether there is enough risk assessment done prior to signing the contract.


Yep, I'm well aware of all of that because I sit on our "Cloud Technology Advisory Committee," which feels like a scene from Brazil. However, many here work with sensitive PHI and various types of classified data, so the concerns are bound to contractual agreements with clients and our ability to win work is contingent upon standing up to audits that verify our claims regarding data ownership, security, etc. I wouldn't argue that makes it more secure, but it's the reality of the business.


Certainly. Another option is HipChat, which you can host on-premise. I actually prefer HipChat because of the simplistic UI. Now both Slack and HipChat support video call is a great plus because I don't have to switch between tools. Slack UI is noisy to me, but the growing ecosystem is fantastic. Ugh.


IRC is also bad because it is too client-side. There is no history: if you're not connected or not in the room, you miss all the messages there. IRC Cloud and similar things half-solve this problem in the ideal situation (eg: nothing fails, such as IRC Cloud connecting to the IRC server), but they are a kludge on top of what is really an inadequate protocol if you want to compare to Slack/Hipchat/etc.

Frequently we will @mention someone in a room that the are not currently in, saying something like "Hm, maybe @person can help with this?" and then they'll get the notification, join the room, read the last bit of conversation, and often provide a solution or something useful. That workflow simply doesn't exist on IRC.

There are a handful of other features that range from really-freaking-nice-to-have to essential, such as user avatars, away status, formatted code blocks, inline image display (upon seeing url), @mentions, @mentions that go to e-mail when you're away, synchronized notifications across multiple platforms, file/image upload (via copy/paste).. Some of these CAN be done with the right IRC client, but they're not universal or standardized.


ZNC. I was seriously thinking of setting up ZNC as service.


IRC Cloud can host private IRC servers for companies. IRC Cloud also has hooks into third-party services like GitHub and Dropbox.


Unless you have a very willing hacker willing to build the integration from scratch, IRC is bad.

There is a hurdle here, but it's not so bad if you're already willing to run your own IRC server. I wrote nodebot[0] to allow machines and scripts to send messages to IRC, it would be a day or so to put an HTTP request handler (apache with a CGI even) in front of this, slap some TLS and http auth on that URL, and expose a webhook that these external services could hit.

One of the great things about slack is that many integrations already exist, so it's often just a matter of sharing an API key or some other credentials between the services, and anyone can do that. I do, however, run into issues with things like github which has many outgoing integrations with services that also use github's incoming API. It can quickly become a mess -- where should the authority lie for doing integrations: with the chat app or with the individual services?

[0] https://github.com/thwarted/nodebot


Established OSS tools like Jenkins already have IRC integration.


> Look at ICQ, Microsoft instant messenger, etc. It seems as though slack like tools get eclipsed every 5-10 years as a new generation comes along with a new favorite tool.

Unlike ICQ, MSN, AIM, YIM, etc., Slack is explicitly intended for companies and businesses to use as a work tool. There are some OSS communities that use it as well, but Slack very clearly discourages that use case.

The "stickiness" of work tools is higher than consumer-oriented applications in general, but especially for something like Slack, which is focusing on integrating other productivity features or products[0], I don't think ICQ is a great pattern of what we should expect.

[0] as we've seen by their announcement just this week


IRC is still alive ;)


It's just a protocol. Like HTTP, FTP...

It's not a client. It's not one companies servers. It's not anything like AOL IM, ICQ, Yahoo Messenger, PowWow...


And that is exactly why it's still alive.


AIM/ICQ is still alive. Yahoo! Messenger is still alive. MSN Messenger has a migration path to Skype. Doesn't seem like that distinction makes a lot of difference.


But it is the exception.


This is a very interesting point. Is there any IP in Slack? Or can Microsoft build it in Office / Skype / etc etc and basically block Slack off of the enterprise?

Building the ecosystem would be tough, but the capability seems doable by Microsoft or any other company with resources (Google?).




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: