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

241–250 of 344 posts

Re: The Horror of Microsoft Teams

#241

Post by arethuza »

mullingitover wrote: post #62
giancarlostoro wrote: post #58

Earlier quoted context omitted.

Slack and Teams are different. Slack has muting. Teams does not.

I'll note that we never actually acted on this plan. The idea came up when we were comparing the two. The designated Microsoft Guy at the office was pushing Teams, because it's free as in beer. However, the inability to mute or leave a channel was a big 'wtf' and I'm honestly shocked that two years later they still haven't fixed it. It was a show-stopper for us back then and still would be now.

Why wouldn't you just Hide a Team you aren't interested in? I've hidden most of the Teams in our organisation because they aren't relevant to me.

Re: The Horror of Microsoft Teams

#242

Post by blub »

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…

That's the point of the OS, offering a standard runtime environment.

Your "perfect" world isn't. It leads to a fragmented landscape of competing runtimes and UIs, is inefficient and results in extra implementation effort.

The JS community can't even be trusted to be stewards of a left pad library, never mind UI environments.

Re: The Horror of Microsoft Teams

#243

Post by michaelmrose »

mort96 wrote: post #205
dleslie wrote: post #154

Earlier quoted context omitted.

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.

To be fair, dark GTK themes don't really work. I say this as someone who uses dark GTK themes. Far too many applications end up with dark text on a dark background, and Firefox applies your theme colors to websites so websites also end up with dark text on dark backgrounds. At least a dark mode created by the application's authors usually works.

Firefox is a special case of stupid as far as themeing. Fortunately it's possible to both make Firefox's ui dark with css and make Firefox use a light gtk theme for websites with an env variable which is the logical choice.

Re: The Horror of Microsoft Teams

#244

Post by blub »

gitgud wrote: post #179
GhostVII wrote: post #169

Earlier quoted context omitted.

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…

Yes, there are benefits to having the OS supply the components; switching themes, familiar design and probably performance gains. But, the trade off is simply unpredictability . The app is assuming that the OS has all the components it needs, at the correct version etc. Not all OS's have all components you think, which leads to unreliable user interfaces, which may work for small applications with only a few OS depen…

All major OSes have better, faster, more flexible UI components. These were invented for native apps.

If a component is not available, it means it's not appropriate for that platform or not part of the UX guidelines.

Re: The Horror of Microsoft Teams

#245

Post by ShinTakuya »

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

I don't think it's impossible to make efficient electron apps. Vscode and discord, for example, tend to be reasonable in my experience. I think it's just that the time saved by not having to maintain cross platform software isn't being reinvested into performance/memory optimisation.

Moreover the ease of developing electron apps has opened the desktop ecosystem to web developers who more often tend to have bad habits because of how forgiving most web dev is.

Re: The Horror of Microsoft Teams

#246

Post by blub »

untog wrote: post #146
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.…

You can make an efficient Electron app, just look at VS Code.

Based on empirical evidence, it seems that humanity can make just one sort of efficient Electron app, and that slot's already filled by VS Code.

Re: The Horror of Microsoft Teams

#247

Post by choppaface »

celim307 wrote: post #223
choppaface wrote: post #180

Earlier quoted context omitted.

In my experience with Slack, vendors are always locked down. A good practice is to create a totally separate Slack instance where vendors and contractors can talk freely with employees. If non-emoloyees are on company Slack, they can pick up IP, be witnesses to harassment, be exposed to PII leaks, etc. Locking down channels is tough. As a company grows, there can be immense confusion when channels pop up all over (es…

Why not create seperate private channels and make vendors single channel users?

I’ve seen that too, but having a whole separate instance gives the users a more flexible environment. There’s also the issue of discoverability... sometimes the company doesn’t want employees and vendors to know that certain relationships exist.

Re: The Horror of Microsoft Teams

#249

Post by michaelmrose »

cameronbrown wrote: post #203
GhostVII wrote: post #169

Earlier quoted context omitted.

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…

And then we end up in GTK hell: https://stopthemingmy.app/ At least the web platform is open enough to do this and still function.

>The problem we’re facing is the expectation that apps can be arbitrarily restyled without manual work, which is and has always been an illusion.

Except for working pretty well on most apps

>However, if you change things like stylesheets and icons, you should be aware that you’re in unsupported territory. Any issues you encounter should be reported to the theme developer, not the app developer.

Themes are rarely problematic and it would take 10 seconds to check if one supposed it to be problematic.

They could perhaps work on solving actual problems.

Re: The Horror of Microsoft Teams

#250

Post by moksly »

lozenge wrote: post #230
moksly wrote: post #196

Earlier quoted context omitted.

I think Teams is exactly excellent because it allows you to secure your collaboration tool. Especially valuable post GDPR where you really don’t want your non-tech savy employers putting privacy data into some online Trello board, or slack/discord for that matter. The fact that teams is just part of your 365 platform is soooo awesome in non-tech enterprise that it’s hard to describe just how useful it is. But basical…

"I love how integrated it is but I had to write code to remove the integration that was counterproductive" I get it, but it seems contradictory, and your workaround is probably beyond reach for many smaller businesses.

I get your point, but I’m not sure you can apply enterprise problems to small businesses. Take my specific example, my department has a mailing list called something along the lines of Digitalisation, we have this because we’re 7000 employees at 200+ locations and you can be pretty sure a teacher at one of our schools don’t know who I am or what my position is called. They would know that they need to contact Digitalisation, so we have a mailing list for it, just like this particular school has a naming list with the schools name in case I needed to contact them.

That wouldn’t really be an issue when you have 50 employees in the same office. Aside from that, I think Microsoft actually ended up adding a standard feature to hide Teams mail-addresses from the outlook addressbook when we raised the issue with Seattle, we just needed the extra “Teams -“ to make it easier to maintain.

Post reply on HN