The Horror of Microsoft Teams
201–210 of 344 posts
Re: The Horror of Microsoft Teams
#202Earlier quoted context omitted.
Reminds me of the NET SEND command in windows 2000-xp. Allowed sending a popup text message to specific (or all with a wildcard!) machines on a network. Sure there were times where such a feature would be convenient ("server going down for maintenance, please save your work", etc), but overall ripe for abuse. They disabled it in a service pack and took it out altogether in subsequent versions.
I caused havoc in high-school with that. And finding a way of executing binaries inside Novell's Netware thing, via the "Open" dialog within any Office application's Visual Basic macro editor haha
That's how we ended up with 8-player age of empires 2 deathmatches after hours ;)
Re: The Horror of Microsoft Teams
#203Earlier quoted context omitted.
My opinion is that the OS should not be responsible for providing native elements to the application. If this is true then the application is tightly coupled to the OS implementing these components. In a perfect world, every application would have minimal dependencies required by the OS, and completely encapsulate their runtime and UI components, making them very portable... which is basically web apps, hence Electro…
I like the application to be tightly coupled to the OS, because then my applications have a consistent UI. All of my GTK apps look great, because I can change the theme for all of them with a single command. With one script, I can switch my entire system from dark mode to light mode, and have all applications have the exact same color scheme - can't do that if every application has their own implementation of the UI…
At least the web platform is open enough to do this and still function.
Re: The Horror of Microsoft Teams
#204For extra fun, block access to the telemetry endpoint and watch Teams' memory footprint bloat to crazy levels as the data accumulates and re-attempts the sending. There's some fun inspecting this data, too..
How would one do this? Just a simple DNS block?
Re: The Horror of Microsoft Teams
#205Earlier quoted context omitted.
Who cares if an application's UI elements look the same across platforms? I want it to work on the platform I am using. I simply do not care what it looks like on someone else's platform, and I especially do not want to pay a performance penalty so some designer can have a virtual feather in their cap over it.
I prefer native widgets to whatever application-enforced fad of the year is current. Apps are lauded for providing "dark mode" now; when ten years ago I simply switched GTK themes. To say nothing of accessibility. We've gone way backwards in UX.
Re: The Horror of Microsoft Teams
#206Microsoft ruins Skype, then tries making their own communication tool. Ugh. What is it again that Microsoft is getting such accolades for? Visual Studio Code is fantastic. Github is great, but they bought that. Office 365? OneDrive? I'll give you those. Hosted Exchange is a thorn in my side. Internet Explorer and Edge are (were?) both a joke. I don't have any experience with Azure. Xbox is great. Their server product…
They are hands down the best not-Apple laptops I've used since IBM stopped making Thinkpads.
Re: The Horror of Microsoft Teams
#207The Teams client is built on Electron? Why? Developers need to stop building slow applications. This is ridiculous. It's 2019 and software is slower than it was in the 90s. It must take an enormous number of CPU cycles to execute simple tasks in an Election-based app. It's just incredibly inefficient. I heard similar things about Slack – that it was built on Node, maybe Electron, and was dog slow, especially to open.…
It's built on Electron and still no native Linux client. There's a web version, but you can't join meetings or screenshare. There are 3rd party wrappers for the web version that enable meetings, but you still can't screenshare. At the very least their web version needs to have parity with the desktop application. It's 2019, browsers can handle voice chat and screensharing!
Edit: probably https://snapcraft.io/teams-for-linux
Re: The Horror of Microsoft Teams
#208We currently use Teams and everyone on the team absolutely hates it. I am actively looking at alternatives such as mattermost or slack to get us onto something that doesn't run like complete garbage. Also, why did this have to be developed using electron? If Teams were a native application, or even written using something on the .NET-side, we would probably have about 20% the complaints we do today. Watching an appli…
There are already a bunch of native Teams/Slack/etc.-like applications. Matrix has a good number of native clients[1]. There's Ripcord[2] which supports both Slack and Discord. There's Matterhorn[3] for Mattermost. [1] https://matrix.org/clients/ [2] https://cancel.fm/ripcord/ [3] https://github.com/matterhorn-chat/matterhorn
Re: The Horror of Microsoft Teams
#209This thread should give some much needed perspective on all the people who assume MS is going to destroy slack. I bet slack destroys outlook before teams destroys slack.
Re: The Horror of Microsoft Teams
#210Earlier quoted context omitted.
This has been discussed many times here... of course running a Chrome instance is inefficient but in some cases that's acceptable. Especially for the gains in cross-platform compatibility and reliable user interfaces. Almost no other platform can guarantee that a UI elements will look pretty much exactly the same on all different operating systems. Most people don't mind the extra RAM consumption for some application…
Who cares if an application's UI elements look the same across platforms? I want it to work on the platform I am using. I simply do not care what it looks like on someone else's platform, and I especially do not want to pay a performance penalty so some designer can have a virtual feather in their cap over it.
Designers.
End users simply want a functional, working product. Polish on top is a nice added bonus, but these days it's been turned into the focal point of software development. A Teams/Slack-caliber project begins with product requirements, immediately followed by design and UI mocks - the software/tech always comes last.