171–180 of 344 posts
Earlier quoted context omitted.
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?
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…
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.
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.
Earlier quoted context omitted.
>The emojis are of bad quality and look like crap. Maybe an oversite on my part, but I didn't even consider this as I was evaluating an enterprise productivity app...
An ugly and unpleasant working environment can affect your productivity.
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.
Earlier 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…
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 dependencies, but as the app grows the reliability decreases...
You're correct in saying the UI should not be the same on every platform (iOS, Android, Windows). But in my opinion the app should encapsulate it's UI and share as little as possible with the host OS.
I use both daily. I think the biggest problem with Teams can't be discovered by feature comparisons and performance metrics. Teams enables a company to "secure" the application in the same way other MS products can be. That makes the product easy to sell, but in practice, it prevents Teams from being an effective collaboration tool. If I want to create a new channel, I need to get approval from IT. If I want to invit…
Locking down channels is tough. As a company grows, there can be immense confusion when channels pop up all over (especially duplicates). Having some friction to creation can be helpful, but that could be simple public “shaming” instead of getting IT / HR in the mix.
When HR thinks its job is to administrate, the company has lost its chance at having a real culture. It sounds like using MS Teams is like having HR administrate over everything you say at work.