Ways scientists use Slack
nature.com
nature.com
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.
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.
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.
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).
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.
https://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.
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.
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?
I am sorry for this geneticist. His life sucks as much as a software engineer's.