Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Horror of Microsoft Teams

medium.com

Post reply on HN
Print view View original

161–170 of 344 posts

Re: The Horror of Microsoft Teams

#161

Post by baroffoos »

naikrovek wrote: post #152
gitgud wrote: post #149

Earlier 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.

The problem comes when you design a UI and then someone else goes to use it and the font in the selects is a different size and ends up cut off. Also windows users regularly complain at me that the ui looks ugly but its just the windows default ui elements they find ugly

Re: The Horror of Microsoft Teams

#163

Post by gitgud »

naikrovek wrote: post #152
gitgud wrote: post #149

Earlier 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.

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 Electron's popularity...

Re: The Horror of Microsoft Teams

#164

Post by addicted »

WiseWeasel wrote: post #122
addicted wrote: post #102

Earlier quoted context omitted.

It's good at chat. It's not good at persistent chat rooms. It's great for ad hoc groups of people to chat or for direct chat. It's also great for meetings. Where it gets cumbersome is in the persistent chat room management. And as someone who is not a fan of chat rooms as a replacement for emails (I can't even filter or categorize information) I'm glad about that part.

Email is great and all, but not for regular topical discussions that may interest dynamic groups of people. A persistent, shared and searchable history and threading enables more effective discussion on a larger scale than practical with email.

Fair enough. Teams sucks for the case where you have a limited topic that you want adynamically changing user list to be able to access for an extended period of time.

I’ll take that in return for it not trying to replace email, which, at the very least has folders, and rules, and starring (nearly every implementation has some version of this), multiple clients, the ability to access from non GUI clients, etc.

I really don’t understand at what point we decided that email sucked and really what we needed was a proprietary solution that are up a ton of RAM and hardly had any ability to customise or optimize in ways thateven non technical people have successfully managed wth email.

For all the non email like features, I.e. instant chatting with an individual, or a group of people, Teams works great.

Re: The Horror of Microsoft Teams

#165

Post by utopian3 »

toxican wrote: post #144
Solar19 wrote: post #139

The 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!

Wow, I’m pretty sure Hipchat is built on Electron and has had all these features for years! Microsoft must really be struggling

Re: The Horror of Microsoft Teams

#166

Post by girvo »

mysterydip wrote: post #120
mullingitover wrote: post #7

> "This means that if someone does @${channel_name} you will get an alert. MS have not implemented muting as a feature. Secondly, for all those automatic/admin channels, you can’t unsubscribe yourself (or at least not with the default policies). Brilliant, isn’t it? Unavoidable alerts that any idiot on any channel can annoy people with." At my last job we figured out the fastest way to get your company off Teams: add…

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

Re: The Horror of Microsoft Teams

#167

Post by rekoros »

utopian3 wrote: post #165
toxican wrote: post #144

Earlier quoted context omitted.

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!

Wow, I’m pretty sure Hipchat is built on Electron and has had all these features for years! Microsoft must really be struggling

What’s Hipchat?

Re: The Horror of Microsoft Teams

#169

Post by GhostVII »

gitgud wrote: post #163
naikrovek wrote: post #152

Earlier 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.

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 components.

And different systems have different UI requirements, so I don't think it makes sense in many cases to have the same UI between them. iOS and Android, for example, have very different standards surrounding what buttons mean, and how the navigation should work. The back button on Android, for example, completely removes the need to a back button in the application, while in iOS it is still required. And of course if you are making an application that runs on both touch screen devices, and devices with keyboards, the UI should definitely not be the same.

Post reply on HN