Same for mobile, the advantage vanishes once enterprise requires your (usually personal) phone to be surrendered to corp IT via MDM (which I sure as hell won't do).
The whole value proposition of Slack and Teams for their customers is control.
...What?
[1] https://docs.microsoft.com/en-us/office365/troubleshoot/acce...
Microsoft uses these anti-features as a selling point, and in a large enough organization, it's not immediately clear who turned them on or who can turn them off.
Imagine an enterprise disallowing all VCS service providers -- whether hosted on-prem or cloud -- because they use SSH instead of HTTP.
Wait? Can you even make API calls to Teams without getting the account owner to make a key for you? I’ve been looking for a way to use a personal key or credentials to make some calls, but the docs are absolutely impenetrable.
Or is this something stupid like a user-agent check?
I don't even blame such enterprises because most of the time it comes from regulations or outside policies that customers mandate, something like all enterprise data (and thus communication) has to be firmly under control of the enterprise with hard guarantees, otherwise you just don't get to work with those customers. So you get a locked down Slack/Teams, and the email+calendar system disallows any native app unless the device is MDM'd, and even that is only with first party clients such as the Gmail app or Outlook.
TBH I think most companies are trying to do their best there, but they're stuck with some kafkaesque liability system.
Taking reasonable measures absolutely does absolve the company. At that point, it becomes a rogue employee who’s deliberately circumvented policies and technical enforcements, who is now potentially personally liable.
It’s garbage, but hey ho.
And consider this also: "hey we're quite sure pur homegrown system is as leak proof as it can be, trust us or fire up an audit team for 5 sprints to asses compliance" vs "Slack has the box checked already"
The fact that folks can e.g technically fire up a headless browser and programmatically interact with the app via capybara or whatever to rebuild a makeshift API, or just take pictures with their phones because the compliant system is inconveniencing them daily is immaterial.
At any rate, for the IRC server at the shop I was at previously, I had "webhook" support/a http(s)->irc gateway implemented on my own in much less than an hour via CGI ;)
long live the Unix model!
In other words:
- to use the slack APIs, you probably need company level buy in _before_ any code is written against the API from IT folks
- in contrast, with IRC one could just try something out and at some point in the future _maybe_ create a seperate IRC account for it, if your IRC server even has logins enabled. If it doesn't, which when I worked for IBM was the case, one can just pick a new username for the IRC bot.
Due to its simplicity I could see its application as a falback for global communication downtime/outages (as we had with FB/Insta recently).
I remember when the solution to this, when everyone was still working in an office, was "pair of netcats".
If something comes of the discussion. Update docs, post the chat log in the wiki, send an email with cliff notes and ask if others care to discuss, halt and get the right people in the room.
When you decide, 'hey, we have an idea, or a change in direction' you'd then document or make the case in a way that is more clear and user friendly than a mile of ephemeral chat. This is the same reason people send out meeting summaries instead of transcripts.
We've moved to this point where nothing is ephemeral. But a random chat isn't a good way to understand why things are being done. It's just too much to parse. And at some point new people are looking for a needle in a haystack and they just kinda checkout.
I thing documentation should be intentional, the why should be clear in a doc that doesn't waste time and is formated in a way that we have come to understand as the best practices of technical documentation. You'd start with a quick overview of both the problem and proposed or adopted solution and the reader can decide if they need more info.
Especially with remote work, I think it's important to have ephemeral areas for discussion without expectations that everyone keeps up on the whole chat. Thinking every team member needs to know every word of discussion is ludicrous.
I’d be fine with all chats being deleted after a month. But if I’m out one day I’d like to see my colleague’s message about the project I currently work on.
Reminds me of this classic: https://www.youtube.com/watch?v=O2rGTXHvPCQ
You need a client and bouncer (or server, if you connect directly) that supports this extension: https://ircv3.net/specs/extensions/server-time
> and limit problems.
ditto, but https://ircv3.net/specs/extensions/chathistory if I understand you correctly.
I do not claim ZNC or our whole IRC setup was perfect, but for me and many others, it did a very decent job of providing effective, no-frills, getting-things-done means of communicating, all while consuming little resources on both server and clients, and being simple, underestandable, and easy to hook other software into.
I really miss it, and personally dislike (especially the client UX of) most trendy/recent alternatives.
I'm actually going to use it to set up my own cloud dev I can access from anywhere, but it has tremendous utility beyond that
To think people build their businesses on this is mind boggling.
Teams seamlessly works across platforms, and mobile with video chat, files, outlook integration, and screen sharing. Maybe IRC could of been that, but it never happened.
I get why it’s designed the way it is, it’s trying to be Sharepoint, Slack, Zoom and Outlook. And as a result it does every single one of them worse.
Sometimes integration is better left as event handlers rather than trying to make IRC behave like a Wiki.
I’d like Teams more if it just focused on the video conferencing side of things. It’s chat and Sharepoint integration just adds more frustration than anything.
Also all video conferencing and chat applications support sharing files. This isn’t some unheard of feature that Microsoft have pioneered. It’s been possible since the BBS days. It’s possible in XMPP and IRC. It’s possible in every other commercial service I’ve used. And I happen to think Teams does it the worst out of everyone of them because of the weird UI decisions and Sharepoint integration. Compare Slack to Teams and you see what I mean. Files are in lined in Slack and it’s easy to preview and work with them. It’s a pain in the arse in Teams. Slack also has all the other features of Teams that you’re boasting about. And Slack isn’t even perfect itself yet it still runs circulars around Teams in terms of usability.
Literally the only thing Teams gets right is the way of marking the confidentiality of shared content. But that doesn’t justify the mess Microsoft have made of Teams UI.
I’m not one of these FOSS evangelists who throws their toys out of the pram if we don’t use IRC. But Teams UI is really just a clusterfuck of bad design decisions. It’s easily the worst designed solution out there. Except maybe WebEx - which is a pretty fucking low bar, scraping the barrel really.
Microsoft know they automatically win the enterprise because of AD and Office integration. So they don’t need to compete on quality. They just need to be present.
Usable is in the eye of the beholder.
Usable as in "I can get a video call going and can send chat messages and files": true.
Usable as in "Easy to use, frustration-free to use, easy to discover functionality": false.
It's an incredible slow application for chat. I don't particularly care if it's just bad programming or an overuse of animations, but it shouldn't feel slow on a beefy computer. Mobile is even worse on a midrange android.
No easy way to quote or forward messages, the stupid distinction between teams channels that have threaded messaging and chat that doesn't, intermittent problems loading images; I could go on for hours.
And this is why myself and others keep saying Teams is garbage. Why settle for something that is only just barely usable when there are a dozen other solutions on the market that are highly intuitive.
I’ve lost count of the number of textual messages I’ve missed in Teams because of the appalling way groups are handled. Or the number of lost conversations because video chat conversations are blended into private 1:1 chats. It’s a fucking mess of an interface. Literally everyone else does it better.
> The mobile app is especially nice.
I couldn’t give a crap about how nice the mobile app is when 99.99% of the time I’m chatting and running meetings from my laptop. I want MS to produce a 1st class productivity tool, not TikTok.
> They are constantly adding features
I don’t want new features. As I mentioned at the start, Teams already has too many features. I just want the core user experience not to suck.
> but already meetings with hundreds of people it handles no sweat
Yet text chat between people sucks and I (like 99% of Teams user base) spend more time messaging people than we do in video conferences for 500+ people.
Your shilling here really does demonstrate just how much Microsoft have swung and missed imo. Both you and Microsoft have completely lost touch with the kind of usage that most people actually need Teams to be good at. I mean yeah, some of the features you’ve described are handy in niche situations but if the average use case is appealing (and it really is in Teams) then you find yourself lusting after other solutions most of the time.
Case in point: At my company I literally pay for Slack despite also having Teams around just because Teams sucks so badly for anything non-video. I guess we could use IRC for free but Slack has better support for in lining files (better than Teams too), better support for Markdown (better than teams too), better search in chats than Teams, better ways of organising conversations. And it’s a thousand times easier to read conversations too. It’s just better in every way for messaging. And with huddle support, it’s also not better than Teams for quick voice chats too.
And if I had to drop Slack then I’d switch to Discord, IRC, XMPP or literal anything before being stuck with Teams for all our non-video communication.
This implies you don’t really care about capability at all. You have some beef with Microsoft where you’d rather have nothing than something to avoid using a product you have a irrational bias against.
No, I said you were shilling. I don’t think you’re a shill but your posts are definitely shilling the product
> and then say you’d switch to IRC over teams.
For text chat. Yes. I also said that was an extreme case however IRC is still more intuitive than Teams for text chat.
> IRC has no features compared to teams - screen sharing, voice/video, threaded discussion, calendars, a mobile client with all these features, etc..
Have you even read a single bloody thing I’ve posted? How many times have I said I don’t give a crap about mobile support because 99% of my usage is on a laptop? How many times have I said that Teams suffers from having too many features rather than doing one thing well.
It’s like talking to a brick wall…
Also I did say IRC specifically for text chat.
> This implies you don’t really care about capability at all
You’re conflating comparability with feature bloat.
I’m all for comparability as long as it doesn’t harm usability. But comparability can be in the form of supporting 3rd party API hooks - it doesn’t have to mean bundling every feature into a confused user interface.
This is where the UNIX philosophy comes in: everything in UNIX is compatible with each other but each individual program is designed to do only one thing and do it well.
Now I’m not saying we should have separate video conferencing, calendars, text chat, etc. However in the case of Teams it suffers from trying to do everything. It’s the “Jack of all trades, master if none”.
So naturally I will use a program that specialises in a specific area well if it improves my productivity. For me using a better text chat solution improves my and my teams productivity vs using MS Teams for everything.
> You have some beef with Microsoft where you’d rather have nothing than something to avoid using a product you have a irrational bias against.
Enough with the name calling. There’s no need. Especially when the issue here is your own reading comprehension.
I’ve given clear reasons why I don’t like Teams. You obviously disagree, which is fine. But at least read my comments before replying with your ridiculous bullshit. “Ridiculous” because you’re consistently citing examples of stuff I’ve already discussed as not a requirement in literally the previous post. Which you’d know if you’d bothered to read my entire posts properly.
One of the downfalls of IRC is the notion that everything should happen in the chat. There's no reason you can't have a pastebin and a file server and screenshot sharing service, most of which don't matter anymore after 5 minutes anyway. It works really well and in fact, we kept using them after switching to fat chat because it was a better experience. There are reasons to want a fat chat client (primarily mobile, imo), but having used both for many years, the featureful chat client ends up being worse than just sharing links most of the time.
* bot spam that I can't /ignore
* "inviting" people to channels tht you can't opt out of (invite is slack terms is yank. there is not option to say no)
* inline sharing of screenshots of article snippets that support an argument but not sharing links to the source material
* so... many... channels...
To compound the problem of many channels the UI uses an insipid three column layout. I like to arrange chat windows, tail -f terminal windows, and other monitoring things in a "dashboard" layout in a workspace. That way it can update in the background and if I am curious about the state of something I can decide to context switch and bring up that workspace to get an update. I can then deal with an issue or go back to the task at hand.
Slack and HipChat and all the other Electron-based attention siphons do not let me arrange their UI in a way that works for me. I hate notifications with the heat of a thousand suns and turn just about all of them off on all my devices. Slack et all hide the state of all but one channel by default and want to use notifications or stupid icons to show there's unread activity. It's the worst UI on the dumbest system but animated emojis!
The rest of the shift is explained by discord being popular for other use cases (e.g. as a twitch companion), overwhelmingly dominated by younger users. IRC isn't getting new users and over time, this means the community will migrate due to turnover. Thank god we at least have things like matrix bridges, but discord is a lost cause.
[1] - https://convos.chat/
[2] - https://thelounge.chat/
[3] - https://www.ilmarilauhakangas.fi/irc_technology_news_from_th...
In the old shop, we eventually had all kinds of important subsystems hooked up to our internal IRC server: Monitoring and alerting. Source control and Wiki activity. The deployment pipeline. Ticket activity reports. All these services were pretty much effortlessly set up to provide useful, real-time status information broadcast to topic-specific channels users could idle in. Everyone could stay informed on topics of their interest, in real time, with no barrier to entry. It was really good, and the implementation completed in a few hours total, for all use-cases, due to irc's incredible simplicity.
Due to the benefits I had reaped from that setup before, I tried to implement parts of it on/for the MS Teams platform at the then-new job. Getting the Teams Python SDK to implement a bot-like entity running alone proved to be a days-long ordeal, and whatever followed wasn't much more pleasant.
In the end, we let someone set up two email-to-teams-channel-forwards which kinda worked, but suffered from obnoxious, multi-minute relay delays.
As a consequence of the tedious bringup and the latency shortcoming, the "effortless notification" initiative never really got traction.
Not only because of this particular experience I am a firm believer that software/system simplicity is a virtue that can neither be overstated in importance, nor substituted by anything else.