17 ms·
The problem with "trying it with my team for one sprint" is that I now need to have a long conversation with legal. How will the service provider handle the con
by legerdemain 6y ago
The problem with "trying it with my team for one sprint" is that I now need to have a long conversation with legal. How will the service provider handle the content (discussions, screenshots, code snippets) that my team will upload? Do our current customer contracts contain any clauses that complicate the use of external discussion sites? In the unlikely event that the service offers the option to host it locally -- who is going to deploy it, configure it, set up security and authn/authz around it?
The real answer is: just fucking use email. Why is email not one of the options suggested in the TFA? It's universally available, durable, allows long-form conversation and thoughtful deliberation, doesn't tell you that "someone is typing," and offers you the luxury of checking it at a set interval only a few times per day.
The way many organizations have collectively abandoned email in favor of instant messaging is a travesty.
- emidln 6y agoMany organizations seem to use Outlook/Exchange and configure Exchange to make it difficult to use other mail clients (not enabling imap, not enabling caldav support so that a separate calendar and email client need to be used unless you use exchange, etc). Outlook is truly awful as a mail client and it would make one want to use anything else.
- legerdemain 6y agoSo you're saying you'd rather lose all the productivity benefits of a solution that's not instant messaging than use Outlook? Powerful stance!
- TheSpiceIsLife 6y agoIs it really that bad? I'm just a dumb machine operator that uses Outlook at work, Fastmail for myself, and Gmail because I'm an idiot too, and really can't tell the difference.
- nobody9999 6y ago>I'm just a dumb machine operator that uses Outlook at work, Fastmail for myself, and Gmail because I'm an idiot too, and really can't tell the difference. Install Thunderbird[0] and use it for a week. You'll be able to tell the difference very quickly. [0] https://www.thunderbird.net https://www.thunderbird.net
- jcrawfordor 6y agoI'm a Thunderbird user, but I don't really think that there's a clear winner in that comparison. Outlook has features that Thunderbird has been missing for over a decade, like reliable send-in-background (and other database operations in background unlike Thunderbird that likes to interrupt you to ask permission) and a far more mature calendar product.
- indymike 6y agoNot to mention replies listed in threads. You have to move sent messages to the inbox to get this to behave correctly in TB.
- Joe_Cool 6y agoRight click -> open message in conversation
- nobody9999 6y ago>I'm a Thunderbird user, but I don't really think that there's a clear winner in that comparison. Outlook has features that Thunderbird has been missing for over a decade, like reliable send-in-background (and other database operations in background unlike Thunderbird that likes to interrupt you to ask permission) and a far more mature calendar product. A fair point. As someone who has used both Outlook (professionally) and Thunderbird (personally) for decades (IIRC, the oldest message in my Thunderbird email store is from 1996), calendaring in Thunderbird isn't as robust as in Outlook and some of the other weaknesses you mention are absolutely valid. However, I'd say that many of the advantages of Outlook that you mention are more related to better integration of Outlook into Exchange back ends than to the Outlook client. If Exchange had better IMAP support and appropriate plugins for Thunderbird, Thunderbird would be vastly superior to Outlook in most respects. As it is, Thunderbird is already vastly superior to any web-based MUA[0], including OWA[1]. [0] https://en.wikipedia.org/wiki/Email_client https://en.wikipedia.org/wiki/Email_client [1] https://en.wikipedia.org/wiki/Outlook_on_the_web https://en.wikipedia.org/wiki/Outlook_on_the_web Edit: Clarified Outlook/Exchange integration vs. Outlook as client.
- bluGill 6y agoOutlook takes to long to start up in the morning. If it could start instantly I'd walk into the conference room on-time, but instead I'm several minutes late. Now that I'm working from home it needs to get the chat client started instead, but the the end result is the same, if I'm not running early I'll be late to important early morning meetings. (my early morning meetings are with India, so they will quickly assume I'm not joining at all and head to their supper - timezones are such that the best time for everyone is my breakfast and their supper) Outlook also has been chasing the flat look fad which is against usability. Most of the others are too so it is hard to fault them, but I still wish they would have the guts to say this fad is wrong... Once they are all running and you are used to the ui quirks they all work well enough.
- GordonS 6y agoThere is something very wrong with your Outlook and/or Exchange install if it takes "several minutes" to start. I've used Outlook in several organisations over the years, and start time has always been in the order of 5-10s.
- berryjerry 6y agoFor me it takes less than 2 seconds to start up fully. Not sure what is wrong with you guy's computers. Maybe you need an SSD or more RAM.
- _4570 6y agoTook about 10 seconds. Using a mobile workstation with an SSD and 32GB of RAM. Maybe I should go for 64GB? :D
- selfhoster11 6y agoOutlook starts faster for me than Slack.
- wussboy 6y agoIt’s the worst. Unless you have to use any of the other ones.
- Aeolun 6y agoIn terms of experience using the product, I feel the Fastmail client handily beats both outlook and gmail.
- TheSpiceIsLife 6y agoI agree, it's the user experience I notice the least. It doesn't get in my way at all, and I don't recall it changing or if it has the changes have been so mild and consistent I haven't noticed.
- Const-me 6y agoI've been using Outlook for 20 years or so, and I generally like it. Lots of features, some of them are borderline unique. For instance, I wonder which e-mail clients allow to create complicated rules that are then running on the mail server as opposed to that client? The necessary conditions are (1) one needs to learn it. Too many features are making UX non-intuitive. (2) fast connection to e-mail server (3) ms exchange on the server, some features only work there.
- welterde 6y agoThat feature of course needs support server-side, but Thunderbird does have a Sieve add-on (in case sieve is enabled/available on the server). I don't use it myself, since I prefer to edit the sieve filter file directly instead of using a GUI for it, but the option is there.
- Const-me 6y agoI prefer to right-click on e-mail and "create rule from message" from context menu. Also, the feature doesn't require any steps to configure, install or enable, it just works out of the box.
- welterde 6y agoUnlike the Outlook+Exchange combination Sieve is an actual open standard (RFC 5228 & RFC 5804 & co) though that can be implemented by all mail servers and mail clients. Or is the Outlook+Exchange feature based on the same? Looking at the sieve website it seems quite a few desktop and web mail clients do have support for it either out of the box or as an add-on. So I would say that having this functionality is more on the "common" side than "borderline unique".
- Const-me 6y ago> Or is the Outlook+Exchange feature based on the same? Not sure but unlikely. It works in Exchange for 20 years now, that RFC was written in 2008. > having this functionality is more on the "common" side than "borderline unique". The complete UX makes it borderline unique. Available out of the box, has a nice GUI, and is reliable in practice.
- dumbfounder 6y agoThose emails are only available to the users participating in them, and in some places are automatically deleted after a certain amount of time. The point of TFA is knowledge capture, and email isn't transparent enough for sharing knowledge.
- legerdemain 6y agoEnter team aliases and topic-based distribution lists. Adding a distribution list to an email thread is almost exactly like choosing a Slack channel to type into, except you no longer have the mess of needing to share and re-share messages and threads across channels. You can just add multiple distribution lists. You can also subscribe and unsubscribe from distribution lists and set up filters for them, which is basically like joining and leaving Slack channels based on your interests, except it gives you much more control over what you want to read and when.
- powersnail 6y agoThis gives me an idea. What about setting up an archiving script? After a archive-worthy discussion in email, you forward the thread to "archivebot@my-company-domain.com". The script will parse the email chain and generate a static web page hosted on a local server.
- Alex3917 6y ago> After a archive-worthy discussion in email, you forward the thread to "archivebot@my-company-domain.com". The script will parse the email chain and generate a static web page hosted on a local server. Unfortunately there isn't any such thing as "forwarding an email thread", at least not currently. If you hit the forward button in your email client it will only forward the last email in the thread, which sometimes contains the entire thread as quoted reply text, but only in situations where each person has only replied to the most recent email in the thread. Some email clients also truncated the quoted reply text after a certain number of messages, and it's not generally parsable. Our email archival product uses a G Suite add-on for this reason, which provides the same benefits as OAuth but works on a thread-by-thread basis. I think Outlook extensions work the same way, but I'm not 100% sure on that. Actually technically Gmail does have a little known "forward thread" button that's hidden in one of the dropdowns, but it doesn't work that well. (Which you'll see if you try it on any longer thread.)
- NationalPark 6y agoEmail isn't searchable by people who weren't on the threads. In an org that uses IM well (they exist!) the chat system actually becomes sort of like a wiki, except a lot more helpful.
- eagsalazar2 6y agoExcept you can only find stuff by spelunking with search, hoping you hit on the right set of keywords and then scrolling through a jumbled mess of hits. Wikis are organized and have navigation. Also being at a company that uses email and Slack, I will say it is very very rare that anyone actually uses Slack to search for conversations they weren't in. Email has other weaknesses of course but in general I agree with the point that Slack is actually worse in many use cases.
- harikb 6y agoOne cannot search channels one is not part of. Don't forget channels. Not everything happens on #general and #random. Also, even if I am part of the channel, there is no way I can search and locate what I want without knowing the right keyword to search for. Sure, the information is all there, but that only ads to the frustration. Search interfaces in Slack & all are very limited / too broad.
- gregmac 6y agoIf someone told me "that is documented in the chat channel, just search", my response would be "ok. So it's not documented." Even with the best organization (old content deleted), I don't want to wade through the conversations about it or all the other noise. Chat is temporal, the discussion about something like "should x be updated" is immediately irrelevant after the decision is made.
- bluGill 6y agoYour point is valid, but not exactly correct. I don't want to know just what was decided, but why. Often I will come back to "should x be updated" again and again. Knowing the factors in the last decision is very important. More than once I've pushed to update x and had someone say "we can't for good reasons that I forget". Often I've spent weeks redoing the discussion before someone remembers/discovers why we can't do the update and we all go "whoa, I'm glad we didn't do that". Other times we discover/remember why we couldn't update and they are for reasons that no longer apply and so we do the update. Still other times we never discover any reason why we shouldn't update. Last sometimes we discover why we shouldn't have updated after it is too late and we have a mess to undo while backing out the update. The important part is we know why a decision was made. Chat logs are not a good archive because there is too much to sort thought that isn't relevant. Better than nothing, but what is really needed is an effort to document why in a place the right people will find it when they need to know.
- DoofusOfDeath 6y ago> The real answer is: just fucking use email. I know of at least one large company that forcibly deletes emails older than N months, as part of their legal retention policy. (I'm assuming it means non-retention to limit exposure to lawsuits.) That would be problematic for persistent documentation.
- munchbunny 6y agoThat sounds like a pathological case. How many companies actually do that?
- res0nat0r 6y agoMost Fortune 500 companies have a document retention policy that every employee needs to read the generic training video/documents on when getting hired and agree to. This sets a general policy of deleting documents/emails/etc after $X days. This is really a CYA policy to purge old conversations if a big lawsuit comes down asking for document retention in relation to some scandal, and if its older than $X days you're covered since your standard legal process was followed.
- sumtechguy 6y agoAlso depending on industry you may by law need to delete things.
- eecks 6y agoWhat is CYA in CYA policy?
- grzm 6y agocover your ass.
- oasisbob 6y agoMany, at least in the US. It's not just companies, government agencies also have similar needs due to sunshine and open-access laws. The alternative to having a document retention policy is to just have employees delete things in an arbitrary manner. It's not just CYA for leaving inconvenient doc lying around, it's also to ensure the proper retention in the event of a preservation order or public records request. Some companies go way further than others. One place I worked included "notes of a personal nature (eg, birthday cards)" in the retention policy and let us keep them for a week or two before destruction.
- mumblemumble 6y agoThere is really only one fundamental problem with email: its mechanism for managing who takes part in the conversation is all wrong for team communication. The symptoms of this problem are myriad: reply-all storms, cya-by-cc, replying to a 5 month old email rather than starting a new thread, fyi forwards, etc. Which isn't to say that all the advantages you list for email are not true. They are. It's just that most people will shy away from an otherwise-decent solution if it has terrible UX.
- throw14082020 6y agoThere are many problems with email, not just one. Sure, we have SPF, DKIM, DMARC and S/MIME, but they're not used by most people. Especially the most important one, S/MIME (to encrypt your messages/ keep them private).
- fractionalhare 6y agoI'm surprised if that's actually true. I would guess that most peoples' personal and work email accounts are managed through providers like Google or Microsoft, which do enforce all of those security protocols.
- GekkePrutser 6y agoTheir business products definitely don't enforce S/MIME by default (which is prohibitively difficult with external contacts anyway), and they recommend to set up the things like SPF and DKIM. They usually don't host your DNS so they can't do it for you (though they do tell you exactly what to set and provide a checker to see if you did it right!)
- franga2000 6y agoAll but the last are used by everyone as it is basically impossible for mail to be accepted reliably from an email server that doesn't have those set up correctly. As for S/MIME, certificates are a pain to deal with for most people and all they really care about is transport-level, not E2E encryption.
- PaulHoule 6y agoI worked at a B2B startup that had chronic problems w/ team members sharing documents in way that our customers thought were insecure. These were some of the biggest companies the world. I asked our biz dev guy who had been trained as a lawyer what to do and he told me to the same thing my accountant does with my taxes: email an encrypted PDF as an attachment and share the password by a separate channel.
- grok22 6y agoThere are various services like WireDoc, ShareFile, etc, or even Mozilla's deprecated Firefox Send that canonized this (encrypt on one channel, share the password on a separate channel).
- ogre_codes 6y ago> just fucking use email. I get you. But also: - Email doesn't retain context very well. If I dig back through my email I might have all of the emails in a thread, or maybe not. - Likewise, I can't send someone a link to a previous emailed conversation so it makes for poor documentation. I can forward an individual email, but not the comment in context. - Email is not easy to index or post up for reference. You can't link it from a wiki or other documentation for example. An internal mailing list with archiving would solve many of these issues and might be the best option, but it's a slightly different solution.
- jshier 6y agoBasecamp does this well, especially version 2, which integrated with email. With version 2 you could have topics in Basecamp which you could post directly do or email and it was searchable and linkable. It was even possible to post messages which were optionally emailed to clients, with their response becoming part of the thread history. Really the best of both worlds. Unfortunately they removed the email feature in Basecamp 3 (and my company upgraded) so we can't do that anymore, but older projects retain their history.
- ogre_codes 6y agoYeah, basecamp is pretty good at this. It is a pretty solid tool for building projects where having communications and documentation is intermixed is important. I didn't realized they removed the email piece... seems like a downgrade. Particularly for projects where you have fairly casual participants.
- deleted 6y ago[deleted]
- StavrosK 6y agoI've commented this too much in this thread, but it's important: Zulip solves all this, has other advantages and a fast and extremely usable interface.
- 6y ago
- baxtr 6y agoI just love well thought out emails. They can provide a lot clarity and be the basis for great discussions.
- grumple 6y agoIs this the part where we pretend your organization doesn’t already use something like a ticketing service, wiki, etc? I find it hard to believe you don’t have any sort of tool to post information already. If it’s true, run.
- withinboredom 6y agoSo, you're worried about this > I now need to have a long conversation with legal. How will the service provider handle the content (discussions, screenshots, code snippets) that my team will upload? Yet you suggest using email where it basically goes (or can be coerced to go) across the internet in plain-text where anyone can read it?
- dividedbyzero 6y agoFor email that conversation probably has taken place already. Also, lots of larger orgs have internal mail servers where this isn't even remotely true.
- alisonkisk 6y agoOrgs have internal chat servers too.
- tidepod12 6y agoThey aren't talking about internal chat. The article suggests trying out several third party SaaS discussion forums like Discourse/Carrot/Basecamp. It's unlikely most orgs have internal servers for these services. GP is pointing out that using these third party SaaS discussions forums is usually a nonstarter unless its first been pre-approved by legal (whereas email is almost certainly already approved).
- tabbott 6y agoSlack and all its clones are based on the chat room model, which structurally has the problem described in this article (and many others for productivity, such as wasting attention). Fundamentally, the chatroom model pioneered by IRC is poor for asynchronous communication because you can't sustain temporally overlapping conversations in a channel. However, you can't "just use email" -- Email's threading model is great for asynchronous work, but it is poor for synchronous communication and also doesn't support modern features that make it easier to communicate ideas efficiently (shared history, markdown formatting, image previews, emoji reactions, etc.). It's essential to be able to have (semi)synchronous written conversations with people you're working with, especially if you don't want to spend your days burning out on video calls. This is why we created Zulip -- it's designed as a real-time communication tool with email's threading model and all the nice features of modern chat apps that email lacks. And the reading user experience is actually a lot better than email, because Zulip provides is designed with the goal of saving time when prioritizing, skimming, reading, and replying to conversations. It's also 100% open source software (not open core!).
- zxexz 6y agoZulip really hits the sweet spot for a communication tool. Especially with large amounts of users communicating across many different threads. The FHIR community "chatroom"[0] is a Zulip server and is indispensable for communication and knowledge building across thousands of users. [0] https://chat.fhir.org/# https://chat.fhir.org/#
- Noumenon72 6y agoI signed up for that to see what Zulip is like, but there are only 19 messages visible if you do that, so I shouldn't have bothered. It seems nice, I guess.
- Cyphase 6y agoNew users on Zulip instances get 20 unread messages by default – I guess you marked one read. The full history is available to you.
- u678u 6y agoTalk to your lawyer on this too. Our lawyer said emails with the lawyer in the conversation will have client attorney privilege, is not court admissible. I dont know about IM.
- dctoedt 6y ago> Our lawyer said emails with the lawyer in the conversation will have client attorney privilege, is not court admissible. That's too-sweeping a statement [0]: 1. Privilege attaches only to communications in the course of seeking legal advice. 2. Privilege is waived — and thus the emails are discoverable by adversaries and admissible in court — if people outside the decision-making group are in the conversation. 3. Privilege doesn't attach if the lawyer is functioning as a business executive or -advisor. 4. Privilege won't apply if the conversation is determined to be part of a crime or fraud. All that said: If a lawyer is involved in the conversation, then the company's litigation counsel will almost-automatically withhold the emails from being produced to an adversary and will list them on a "privilege log." That will often set up an ancillary court fight over whether the emails should be produced to the adversary. In that ancillary fight, the judge might end up reviewing the emails "in camera," i.e., without the adversary seeing them, to decide whether the privilege applies — and depending on the content of the withheld emails, having the judge read the emails could do as much damage to the company's case as anything. [0] https://www.nolo.com/legal-encyclopedia/attorney-client-privilege.html https://www.nolo.com/legal-encyclopedia/attorney-client-priv...
- StavrosK 6y agoUse Zulip. It solves all the problems that email has and also enables a bunch of other things you never knew you needed, like a sane model for browsing messages. It can even serve as real-time communication for #random and other such work-adjacent channels.
- Aeolun 6y agoTrying to have sensible conversations in an enterprise email client, where 90% of the messages are just garbage is basically impossible for me.
- slykar 6y agoI'm not sure what you mean by the universal availability of the email. It has the same deploy/configure/security issues any other tool has. It's even worse, because you can send email to "outsiders" unless certain rules are in place. The UX is bad and depends on email clients.
- bandris 6y agoOne problem/feature with email is that that new collagues do not see historical conversations. While the typical chatroom is searchable.