And if the client used some kind of reliable and fault tolerant connection method so that the app open opened up and connected really quickly instead of being behind layers of websocket over socket handshaking. At the moment it takes nearly 30s-1m from open to latest chat message visible.
Instead of improving the speed they've put more effort into making the loading screens dynamic and appealing, which is quite myopic.
I think i've written to Slack over 2 years ago letting them know how painful it is to use slack in Africa, Australia or where latency is high (even with a fast connection). I was hoping their valuation and billions and funding would help them improve their software or even make a native mac app.
They have a native(if electron can be called native) App now for mac. I agree with the latency and performance issues though.
The Slack app practically freezes on changing network or if you wake you mac from sleep.
The way chat threads are currently implemented (in chat apps other than Slack) are kind of sucky. I hope Slack doesn't do the same.
Basically, the UX of chat means that threads are typically inline in the chat room or channel. This means that your threads are constantly "disappearing up".
A better approach (from a UX standpoint) is to make threads first-class entities and have ways to organize threads.
TMail21 (https://tmail21.com) takes just such an approach. As such it is much more geared towards the asynchronous (offline) use-case than the synchronous (real-time) use case of chat apps.
I think Google Wave debacle is a great example of how the advice/vision dished out on HN is disconnected from the reality of consumer experience/expectations.
With Wave Google saw writing on the wall and discontinued Reader and GChat XMPP integration.
That walled garden with better user experience are more successful than open standards where user experience might be difficult to due to issues in changing protocol specifications.
Google Wave was an undertaking born directly out of advice-given/beliefs-held by people similar to those on HN. The advice being all you need is a decentralized protocol like Email/XMPP and its possible to succeed in Social. Google tried that with Wave and failed spectacularly. As a result it stopped listening-to/caring about what tech-savvy users say and started dismantling other open standards social tools such as Reader (RSS), XMPP etc.
from what I remember on their demo at some point was they had some cool instant-translation and other stuff built in... forgive the comparison: but much like bots that would do work as you typed. I haven't seen (or noticed) this kind of functionality in docs.
tldr; some labs adopt a proprietary communication and content management system (instead of using existing open protocols) because they don't have the technical support, or time, to do it right.
In the short term this increases productivity but in the long term the lock-in will constrain.
At the largest CS schools there was some use of a federated Zephyr system for a while from the early 1990s to the mid-2000s. While Zephyr the protocol isn't great, the culture was. And being based on an open protocol and Open Source codebase — since it came out of MIT Project Athena — lots of fun hacks were written atop it too.
Also, the primary client "zwgc" (Zephyr WindowGram Client) could run reasonably on a low end workstation like a DECstation 3100 or SPARCstation 1 (8MB RAM, 25MHz RISC CPU, thin Ethernet or SLIP/PPP via dialup). None of this megabytes-of-HTML-and-JavaScript, gigabytes-of-RAM nonsense.
The very few examples cited in the piece represent outliers. I don't have any peers who are chatting on Slack. Email is fine, and most people know that distractions (like HN) are the devil's work.
In every industry that I have worked in, there has always been a battle between using the latest innovative technology to improve everyone's job, and holding back to ensure that nothing breaks. I've always been an advocated of the latter and it appears that some industries may not be ready to start using slack.
Take Ginkgo Bioworks, for example. Sure, being able to open a door through slack because you don't have your keycard is convenient, but this introduces a few security holes and likely makes the whole keycard system useless.
Also, there doesn't seem to be any mention of the need for data security in the article, but it should be noted that slack does not use end-to-end encryption, so they can read everything your organization shares. And, even if they are a trustworthy third-party, they have been hacked before (http://www.businessinsider.com/slacks-security-breach-may-be...), so it's worth noting.
How is browser-based chat like Slack "the latest innovative technology?" It's just IRC or Zephyr, but accessed via a browser. It's not something people didn't have in the early 1990s. Hell, it's not substantially different than AOL or Yahoo chat rooms either, except that it's so heavyweight you couldn't even think about accessing it from systems that accessed those just fine.
Many people including me say this but people do not want to see it. It is even worse tham IRC imho as the clients are slow and wonky, they just 'look better' which is perception. They did their marketing very well indeed.
Slow, wonky, heavyweight clients are not a factor in productivity. If it takes an extra 1 second to send/display a message, it doesn't matter. The communication is close enough to real time. The tradeoffs (which are being massively and hilariously exaggerated here) are worth it because anyone can easily use it from anywhere without having to stay connected or set up logging systems etc.
You are obviously on solid internet. I am almost never and then Slack is unusable because of those performance issues; they are enlarged 100x because of performance. If my connection is wonky and I have a window of less than a second to pass my message in and get messages back, that 1s wait for the client is what makes it exactly unsusable. Wechat and Whatsapp understand this; Slack assumes only people in highly connected cities use it, which ofcourse is normally the case. But that does not make it's problem less real for a lot of people around the world. Most of China for example.
And losing messages, which actually happens when I have bad connections, is a problem; a) i have to type them multiple times and that takes me out of concentration b) i assume that my colleagues read something while they never got it. Large issues indeed.
Are you full time remote working on this internet connection? Seems like perhaps you need to upgrade your connection vs demand everyone switch tools to support your 3rd world internet connection? Do you get mad if people email you attachments too?
I don't get mad nor am demanding anything from anyone. I don't think it hurts anyone if programmers would make connections more fault tolerant. And I don't have a choice; there is no 'upgrade' in most cases. But nice that you don't have that issue.
And your employer is OK with you working remote on a flakey internet connection? I can't say I would hire someone remote that can't get past a 99% or so uptime... if their internet is that bad, they would need to move to come into the office or find another position.
This isn't trying to be some kind of espousing my values on someone, but it seems a basic requirement to work remote. 99% of programming jobs have an office. If your net is not stable, those seem a better fit.
As a person who as a general rule does not care very much about how something looks and only how it functions I am still open to the idea that for a large part of the population the appearance of a thing can have an effect as great as its functionality on their ability to use that thing.
I agree with you. Just saying I do not have that does not mean I strive to make thins look and work better as I know it works for other people. Not that I think Slack is that brilliant UX wise, I can see why people like it more than ancient chat clients. However when productivity, again, for me, comes in, peformance is highly important.
I say "browser-based" because Slack, HipChat, et al are chat platforms you need to use a browser — or something that embeds a browser, like their official apps — to access. They may have gateways to standard protocols like IRC, but those are gateways, need to be enabled on a per-project basis, and may even be extra cost features.
If you don't see why I'm comparing something like Slack to AOL chat rooms and Yahoo Chat, perhaps you don't understand what Slack is as well as you think you do. The fact that you can set up an instance for a team or organization isn't what's important in the comparison, it's the scalability of the service and the degree of client resources used.
IRC has the serious downside that it doesn't allow multi-line comments.
Zephyr is fine but still takes a lot longer to learn how to use, especially if you want to set up a screen session as most people who still use it in my social circle do.
I should have used quotes. When I said "the latest innovative technology", I meant it somewhat sarcastically. Nonetheless, there are people/companies/industries to whom it does seem completely new and innovative. I'm worried for them because they are awestruck at how "cool" it is and how it allows them to do work better, but they fail to realize the possible ramifications of using a product that's new to them.
Yes, perhaps in a business sense, not in a technical one.
(Slack even disallows the use of one account for multiple teams, so they are conveniently circumventing the sharding problem, so no technical innovation even there).
To be honest, I'm a bit disappointed when I see open source projects adopting closed source platforms. While they can have similar functionality with Matrix, without having to support a Matrix instance.
I'm constantly amazed by professionals who complain about their email inbox. Do they not bother to learn their tools, and set up simple mail filters?
Mailing lists are actually one of the best collaboration tools available because:
(1) They can be, but don't have to be, nearly real-time;
(2) The content comes to you, you don't have to check it;
(3) They allow a full suite of content to be exchanged, if participants are willing to accept the overhead; and
(4) They're straightforward to build tools atop, including archives, autoresponders, and various kinds of automation.
Realtime tools like IRC & Zephyr and their awful browser-based clones like HipChat and Slack can be useful too, but should be treated as supplements, not primary.
Web forums aren't quite as awful as browser-based chat, but they're generally better treated as a front-end to a mailing list for people who don't otherwise have access to a good mail client.
(Really, all of this would be even better served by NNTP instead of mailing lists, but almost nobody runs organizational NNTP servers and mail clients long ago dropped support for it.)
Managing my office's IT, this is absolutely how I feel about it. If their job depends on technology X, they should master technology X! But through experience I know that this isn't what happens. The technical stuff is my job. I'm responsible for holding hands and getting everyone to the level they need to be at. If I don't go out of my way to bring people along, they won't even think about it.
You're leaving out the time it takes to learn enough about email to know what the correct configuration is. And you're assuming that you're going to get the configuration right the first time and not have to continually tinker with it.
But, I have work to do, too, and I have many rules set up for my inbox. I receive about 300 emails a day from automated processes and another 50 or so from actual people I am collaborating with. Without filtering I would drown in email. So the filtering makes me more effective at getting work done.
The groups I've worked with, you can't rely on people using filters, formatting or even search effectively because they use the outlook web app, or similar.
Email as a collaboration tool is a strong as the dumbest email client in the group. With slack, there's on boarding and a consistent client so better chance of better use.
> Do they not bother to learn their tools, and set up simple mail filters?
Most people have similar needs, and most people's job is to actually do their job, not mess with their email config. Defaults are important.
A group conversation should be represented in a first-class way as a group conversation - flattening it down into a bunch of fake person-to-person messages and then trying to guess the information that you threw away is dumb.
NNTP is ok, but still built for a time when the network was much more expensive and less reliable than it is now. For a realtime-like conversation it adds a lot more overhead than a Slack-like system - you can't make a 1-line contribution because you have to formalize it as a post, and everyone has to read everything twice because the bottom-posting culture from the days when server interconnection was unreliable has been passed on five-monkeys style.
In theory open standards should make it easier to build archives, autoresponders, integrations etc. In practice, the state of archives, autoresponders, integrations and so on for mailing lists is much worse than that for Slack et al. (I suspect because everyone knows there's no money in it). e.g. Mailman was written by a couple of students a decade ago and has barely been updated since, and it shows.
Because it depends on how you want to use email. eg I have emails which are sent to my address+subs@gmail.com being put to a label "subscriptions", but obviously not everyone wants to use it like this, in which case why make it default?
Because good configs are personal, not global. An email workflow for an accountant would be very different than an email workflow for an HR manager and a CEO.
So, in our lab we do bio-optics (fiber-optics to shine light into a mouse brain and drive it around a cage, that kinda stuff). We tried using Slack in the lab, a few grad-students were really pushing for it and using it.
It failed miserably. Other users echo some of the reasons better but we could not pay for it (not in the budget)so our data got 'locked up' from us after ~6 months when it auto-deleted. That was not a good lab meeting to be in.
We 'siloed' ourselves and it became just a crappy online lab-book that your boss could look at. So, then you have people just typing to seem like they were doing stuff and never talking to one-another. That is to say: useless. Again, not a good lab meeting to be in.
Still, to the point I am replying to: We are scientists, not 'programmery' people, so that that into account when I ask these questions:
What is a config? How do I set up a mailing list and then take people off it too? What is a mail filter and how do I use it? What are IRC and Zephyr?
Ok, also, look, I am NOT going to make my PI or other lab mates into programmer people, most of them never took calculus nor know formal If-Then-Or-And logic trees. They do mice and cells and DNA and stuff, not electrons and motherboards and stuff. At last check, my PI has 120,000+ emails in her 'inbox' on Outlook and I don't know for certain if she actually knows what counts as spam or not or how to delete an email. If I can't explain, teach, and implement these tools in less than 45 minutes in a single lab meeting among all the Windows and Mac versions out there simultaneously with the other lab members, then forget it. It will not happen.
Is there any hope? Because Slack seems so cool (and was for ~6 months before out data got deleted), and your ideas on how to implement it with email seem like they could really work well, but I mostly understand nada about it.
Slack has an education discount of 85%. With that, it's only $12 per team member per year. If e-mail isn't worse than spending $12/year, then you don't really have a problem with e-mail.
Very disappointing to see such a fluff piece in Nature.
One scientist who says "I have a lot more discipline" while another says "“I'm just typing whatever comes into my head".
The "ability to incorporate 'bots'" is lauded as a feature, suggesting that it's not possible with email while further down reporting how one lab has triggers from email to post to Slack.
To top it all off, every "feature" of Slack mentioned is also a feature of email.
Any service that has group chat and the most basic API to just read and write messages can have bots. Stuff like providing button options or inlining images is just icing.
If anyone from Nature/influential is reading, you cant even close your Nature.com account. I tried closing my 10 year old account, they replied that according to terms and conditions I _had_ agreed while opening the account, it will stay forever.
The features of slack I like that traditional irc lacks
* Sms 2 factor authentication
* Historical logs
* instant search
* Offline messages
* The client isn't called "BitchX"
It's replaced IRC at my work because our own irc servers were cert based which is a pain to set up, but mostly because you don't miss things when you're offline, it's easy to get new starters and non tech people (especially developers) on board, and the history functionality is seemless.
- Eh, that is increadibly easy for an IS/IT team to set up and run.
* instant search
- As ^
* Offline messages
- It is called an IRC bouncer - again easy to set up and run
* The client isn't called "BitchX"
- mIRC, XChat, irssi, weechat, KiwiIRC, the list goes on. Not using IRC because you don't like the name of one client out of probably hundreds short sighted. (and you know you can connect to slack from BitchX right?)
I grant it is not perfect, and for some use cases just paying the money to slack is worth it, but IRC can have most of these features.
So IRC is giving me a subset of Slack features, at the expense of
1) IT team to set it up
2) IT team to maintain it when it breaks
3) Servers to run it on.
And give up features such as a nice phone client?
What size of company are you? A 5 person company can use slack for free or ~$480 per year. You are going to have trouble getting all 3 of the above for less than that price. And even if you do equal the price, you, as you admitted, lose features like a nice mobile client.
If you are a 200 person company you can make a better argument on the price front, but then you have kinds of new things like legal discovery requirements. Those will add much time and complexity to your IRC setup. And you still are missing lots of Slack features.
IRC has never been that great. It works. It's a free standard. It's not great.
1) You don't need a team, just a subset of an existing team. One person can do it.
2) Same as above. The time-sink in that is quite minimal.
3) We just run it on an existing mail server. No additional server required.
I agree it could heavily depend on the size of the company, but I'd argue bigger companies have an even greater incentive to keep things on their own servers, and probably more resources for doing so.
I can't account for any of the other slack features as I've never used it, so I'll have to take your word for it.
Depending on your size, a "few bucks" is actually a substantial amount of money, and even a inefficient IT dept hours would be a drop in the ocean compared to it.
There are a few decent phone clients, and KiwiIRC is fairly responsive from what I remember.
not really. channels from other teams are hidden, and you can't tell if there is a message in a channel you care about, or a random / general channel, without swapping to that team.
Luckily Slack isn't that big a deal abroad. For instance, we didn't jump into that wagon since it cost money. We tried MS Teams, I was able to argument our people off of it.
In my uni, I strongly forbid use of any proprietary apps, as much as possible. Please forgive me, I do agree software devs needs to eat ... etc. but let me explain.
We all moved to macs in the last 5 years, which means when I upgrade from mountain lion to Mavericks to sierra, we need to get a BUY Endnote. Every second major version of OSX needs and new EndNote. Even with academic license, it costs, about EUR 600 for every device. 1 Prof, 2 Staff scientists, 4 postdocs, 6 PhDs (charged a bit lower EUR 200 per year). You calculate. There are universities where Endnote is cheaper but subsidized by the bulk-contracts.
Oh yes, we do use MS-office. Atleast MS does not force us to buy new MS-Office for every OS upgrade. Also remember, that grants pay mainly for equipment and rarely any/expensive software.
As other posters indicated, mailing-lists + proper filtering is the optimal.
I don't get why people still use proprietary software for team communication. Slack is just a glorified IRC owned by a private company that you have to pay to get something remotely useful. My teammates hate me for not even having slack installed on my computer.
The phone apps work, but they are react-application web views. At least on Android. I saw that they had an open hiring req for a React Native person recently, so I suspect that is about to change.
I was on the same boat given that I have used IRC for since the 90s. The one thing that Slack does solves is IT. It makes IRC "enterprisy" which means that IT can do account management, tie it with authentication etc..
The second thing it solves is management buyin. At my company we used Lync and I tried to introduce Hipchat, but nothing worked until the company President explicitly bought in to the idea of Slack. Not sure who or what convinced him but he made it clear that it's the tool he wants to use. Pronto, all 500 employees (baring some of us older guys), clicked their heels and marched.
IRC works great as technology and I love it. But Slack solves management issues and as a company I think that's their biggest advantage.
HN loves to hate it and I know I should treat it as unencrypted as the crypto might or might not be good but both mobile and desktop clients works nicely (actually IMO brilliantly) across Android, IPhone, Linux desktop and Windows desktop. Bonus points for bot API and channels.
I agree. I work in a robotics lab with 30-40 members and choosing our basic support software can be really challenging. We avoid proprietary apps until we have no other choice.
We also prefer to have software we can self-host, review the code, and extend. Aside from cost and compatibility concerns, many of our projects have data protection requirements (ITAR, IRB, HIPAA) that can be difficult to maintain with proprietary systems.
Sometimes it sucks to not be able to jump to using the latest big thing, but it's often more important to have software we know will be sustainable.
It works well in our research center. It offers advantages over mail (instant, accommodates multiple people writing short messages at once) and IRC (file sharing with preview, longer posts, editable messages, zero configuration client software). With its multiple modes of communication it works both for people who are in the lab and those who spend most of their day at the desk. The search is a big advantage too. It is better than any search in email clients or IM clients I have seen. It even looks into files. With the academic discount it also comes at a reasonable price.
I don't want to make this a sales pitch, but unlike earlier collaboration tools, Slack actually adds some value. Competitors are well advised to study its features.
Do you find that you spend collectively more time checking Slack than you used to spend dealing with email? Do you think you spend more time in switching costs from concentrating on your work to focusing on the Slack conversations? I've found it to be analogous to converting all my emails and meetings into a 500 mini meetings and email but spread across the whole day with no real opportunity to compartmentalize them.
No, I don't. When the messages become a distraction, you can just snooze the notifications for a few hours. If a message pops up in a channel with a topic that isn't a priority, you can just leave it unread until the more important things are dealt with. In these regards Slack is not very different from email for me.
I think it's not quite right and fair as people keep comparing email vs Slack. Email is a open info transfer protocol, anyone can create their own email system as long as they follow the email protocol, however, Slack is app and owned by a company. Yes you can say it has some advantages than email, but, I hard to believe that people willing to shift from a protocol to a specific software – this sounds to me like people give up on buying appliances which computable with standard power outlet, and get started buying appliances from a specific brand and these appliances can only plugged into this brand owned power outlet. I think this is ok as long as you are a big fun of this brand and bless the it will not be disappear early than you :-)
103 comments
[ 3.7 ms ] story [ 162 ms ] threadhttps://twitter.com/SlackHQ/status/804971838271004672
As an aside, I think it's delightful someone made a Twitter handle named @slackThreadsYet for this.
Instead of improving the speed they've put more effort into making the loading screens dynamic and appealing, which is quite myopic.
I think i've written to Slack over 2 years ago letting them know how painful it is to use slack in Africa, Australia or where latency is high (even with a fast connection). I was hoping their valuation and billions and funding would help them improve their software or even make a native mac app.
https://zulip.org/
https://www.flowdock.com/
Basically, the UX of chat means that threads are typically inline in the chat room or channel. This means that your threads are constantly "disappearing up".
A better approach (from a UX standpoint) is to make threads first-class entities and have ways to organize threads.
TMail21 (https://tmail21.com) takes just such an approach. As such it is much more geared towards the asynchronous (offline) use-case than the synchronous (real-time) use case of chat apps.
All the ground-breaking features, such as live interactive multi-user caret presence are part of Docs. Did Wave promise more than that?
What are the missing pieces that got lost along the way, and never made the jump?
I think Google Wave debacle is a great example of how the advice/vision dished out on HN is disconnected from the reality of consumer experience/expectations.
With Wave Google saw writing on the wall and discontinued Reader and GChat XMPP integration.
That's not what I remember about Google Wave. Where are the moments of these facts recorded?
And because that protocol didn't work, they killed off and/or radically altered unrelated chat and RSS products?
I don't feel that's true. Google has implemented other new consumer facing protocols and products since then.
What are the pieces that tie together Wave, Reader and XMPP integration, other than timing and the fact that RSS and XMPP are open standards?
In the short term this increases productivity but in the long term the lock-in will constrain.
Also, the primary client "zwgc" (Zephyr WindowGram Client) could run reasonably on a low end workstation like a DECstation 3100 or SPARCstation 1 (8MB RAM, 25MHz RISC CPU, thin Ethernet or SLIP/PPP via dialup). None of this megabytes-of-HTML-and-JavaScript, gigabytes-of-RAM nonsense.
And losing messages, which actually happens when I have bad connections, is a problem; a) i have to type them multiple times and that takes me out of concentration b) i assume that my colleagues read something while they never got it. Large issues indeed.
This isn't trying to be some kind of espousing my values on someone, but it seems a basic requirement to work remote. 99% of programming jobs have an office. If your net is not stable, those seem a better fit.
https://get.slack.help/hc/en-us/articles/201727913-Connect-t...
Comparing to AOL and Yahoo is just silly — neither solution offered a way to create private lists of channels and users within a particular Team.
If you don't see why I'm comparing something like Slack to AOL chat rooms and Yahoo Chat, perhaps you don't understand what Slack is as well as you think you do. The fact that you can set up an instance for a team or organization isn't what's important in the comparison, it's the scalability of the service and the degree of client resources used.
Zephyr is fine but still takes a lot longer to learn how to use, especially if you want to set up a screen session as most people who still use it in my social circle do.
(Slack even disallows the use of one account for multiple teams, so they are conveniently circumventing the sharding problem, so no technical innovation even there).
Mailing lists are actually one of the best collaboration tools available because:
(1) They can be, but don't have to be, nearly real-time;
(2) The content comes to you, you don't have to check it;
(3) They allow a full suite of content to be exchanged, if participants are willing to accept the overhead; and
(4) They're straightforward to build tools atop, including archives, autoresponders, and various kinds of automation.
Realtime tools like IRC & Zephyr and their awful browser-based clones like HipChat and Slack can be useful too, but should be treated as supplements, not primary.
Web forums aren't quite as awful as browser-based chat, but they're generally better treated as a front-end to a mailing list for people who don't otherwise have access to a good mail client.
(Really, all of this would be even better served by NNTP instead of mailing lists, but almost nobody runs organizational NNTP servers and mail clients long ago dropped support for it.)
You know the answer. They don't, because they have actual work to do.
Email as a collaboration tool is a strong as the dumbest email client in the group. With slack, there's on boarding and a consistent client so better chance of better use.
I'm not for slack either, just meant to say that it currently offers more consistent short term upgrade over lowest-denominator email clients.
Most people have similar needs, and most people's job is to actually do their job, not mess with their email config. Defaults are important.
A group conversation should be represented in a first-class way as a group conversation - flattening it down into a bunch of fake person-to-person messages and then trying to guess the information that you threw away is dumb.
NNTP is ok, but still built for a time when the network was much more expensive and less reliable than it is now. For a realtime-like conversation it adds a lot more overhead than a Slack-like system - you can't make a 1-line contribution because you have to formalize it as a post, and everyone has to read everything twice because the bottom-posting culture from the days when server interconnection was unreliable has been passed on five-monkeys style.
In theory open standards should make it easier to build archives, autoresponders, integrations etc. In practice, the state of archives, autoresponders, integrations and so on for mailing lists is much worse than that for Slack et al. (I suspect because everyone knows there's no money in it). e.g. Mailman was written by a couple of students a decade ago and has barely been updated since, and it shows.
This is such an obvious excuse. You get the config right once and you've solved a problem forever. It is, how do you say, very "scalable" in time.
It failed miserably. Other users echo some of the reasons better but we could not pay for it (not in the budget)so our data got 'locked up' from us after ~6 months when it auto-deleted. That was not a good lab meeting to be in.
We 'siloed' ourselves and it became just a crappy online lab-book that your boss could look at. So, then you have people just typing to seem like they were doing stuff and never talking to one-another. That is to say: useless. Again, not a good lab meeting to be in.
Still, to the point I am replying to: We are scientists, not 'programmery' people, so that that into account when I ask these questions:
What is a config? How do I set up a mailing list and then take people off it too? What is a mail filter and how do I use it? What are IRC and Zephyr?
Ok, also, look, I am NOT going to make my PI or other lab mates into programmer people, most of them never took calculus nor know formal If-Then-Or-And logic trees. They do mice and cells and DNA and stuff, not electrons and motherboards and stuff. At last check, my PI has 120,000+ emails in her 'inbox' on Outlook and I don't know for certain if she actually knows what counts as spam or not or how to delete an email. If I can't explain, teach, and implement these tools in less than 45 minutes in a single lab meeting among all the Windows and Mac versions out there simultaneously with the other lab members, then forget it. It will not happen.
Is there any hope? Because Slack seems so cool (and was for ~6 months before out data got deleted), and your ideas on how to implement it with email seem like they could really work well, but I mostly understand nada about it.
One scientist who says "I have a lot more discipline" while another says "“I'm just typing whatever comes into my head".
The "ability to incorporate 'bots'" is lauded as a feature, suggesting that it's not possible with email while further down reporting how one lab has triggers from email to post to Slack.
To top it all off, every "feature" of Slack mentioned is also a feature of email.
* Sms 2 factor authentication
* Historical logs
* instant search
* Offline messages
* The client isn't called "BitchX"
It's replaced IRC at my work because our own irc servers were cert based which is a pain to set up, but mostly because you don't miss things when you're offline, it's easy to get new starters and non tech people (especially developers) on board, and the history functionality is seemless.
- Yup, slack has IRC beat there
* Historical logs
- Eh, that is increadibly easy for an IS/IT team to set up and run.
* instant search
- As ^
* Offline messages
- It is called an IRC bouncer - again easy to set up and run
* The client isn't called "BitchX"
- mIRC, XChat, irssi, weechat, KiwiIRC, the list goes on. Not using IRC because you don't like the name of one client out of probably hundreds short sighted. (and you know you can connect to slack from BitchX right?)
I grant it is not perfect, and for some use cases just paying the money to slack is worth it, but IRC can have most of these features.
(I do admit I've not seen a good IRC phone client)
1) IT team to set it up
2) IT team to maintain it when it breaks
3) Servers to run it on.
And give up features such as a nice phone client?
What size of company are you? A 5 person company can use slack for free or ~$480 per year. You are going to have trouble getting all 3 of the above for less than that price. And even if you do equal the price, you, as you admitted, lose features like a nice mobile client.
If you are a 200 person company you can make a better argument on the price front, but then you have kinds of new things like legal discovery requirements. Those will add much time and complexity to your IRC setup. And you still are missing lots of Slack features.
IRC has never been that great. It works. It's a free standard. It's not great.
2) Same as above. The time-sink in that is quite minimal.
3) We just run it on an existing mail server. No additional server required.
I agree it could heavily depend on the size of the company, but I'd argue bigger companies have an even greater incentive to keep things on their own servers, and probably more resources for doing so.
I can't account for any of the other slack features as I've never used it, so I'll have to take your word for it.
There are a few decent phone clients, and KiwiIRC is fairly responsive from what I remember.
Its a pretty terrible design.
I am sorry for this geneticist. His life sucks as much as a software engineer's.
Oh yes, we do use MS-office. Atleast MS does not force us to buy new MS-Office for every OS upgrade. Also remember, that grants pay mainly for equipment and rarely any/expensive software.
As other posters indicated, mailing-lists + proper filtering is the optimal.
http://endnote.com/buy http://www.adeptscience.co.uk/products/refman/endnote
The second thing it solves is management buyin. At my company we used Lync and I tried to introduce Hipchat, but nothing worked until the company President explicitly bought in to the idea of Slack. Not sure who or what convinced him but he made it clear that it's the tool he wants to use. Pronto, all 500 employees (baring some of us older guys), clicked their heels and marched.
IRC works great as technology and I love it. But Slack solves management issues and as a company I think that's their biggest advantage.
Make an free/opensource product that will do that for me with no configuration or administration effort and I'll gladly use that instead.
HN loves to hate it and I know I should treat it as unencrypted as the crypto might or might not be good but both mobile and desktop clients works nicely (actually IMO brilliantly) across Android, IPhone, Linux desktop and Windows desktop. Bonus points for bot API and channels.
A lot of smart people who are old enough to be familiar with IRC see it differently. See comments from old HN thread:
https://news.ycombinator.com/item?id=10486541
Many many not use Slack but they certainly can see the value of it over IRC.
We also prefer to have software we can self-host, review the code, and extend. Aside from cost and compatibility concerns, many of our projects have data protection requirements (ITAR, IRB, HIPAA) that can be difficult to maintain with proprietary systems.
Sometimes it sucks to not be able to jump to using the latest big thing, but it's often more important to have software we know will be sustainable.
I don't want to make this a sales pitch, but unlike earlier collaboration tools, Slack actually adds some value. Competitors are well advised to study its features.