Linux looks like it won't happen until 2022 but Mac is first. I'd guess they are aiming to have it release around the same time as a bunch of other stuff this Fall but still can't commit to that date yet.
Well if it’s prebundled, I guess it will be properly audited and hopefully less evil than Zoom.. which has been known to install services on your PC that are easily exploitable.
It had better use less memory. Currently it runs at about a gig on my machine, without any meetings in progress.
This is about 8-10 times heavier than the Skype for Business client was.
WebView2 looks to be a great choice instead of Electron, now that they're shipping Edgeium everywhere. The old IE WebBrowser control has been a non-starter for a while.
Drop Electron.... for Edge Webview2. I mean, okay sure, half the memory is an improvement. But what is going on in the chat industry that everyone's converged on Electron? You'd think Microsoft of all companies would be able to figure out how to build native apps. If I want a chat service with native apps, it seems like my only option is IRC.
Going through the sunk cost of making 5 different GUI's and maybe wrapping some syscalls/API for the same 90% core app, resulting in minimal resource usage. It's the correct computerscientific approach and companies like Microsoft can (and should) commit to it. Breaking changes nowadays are too few and far between.
I don't think RAM conservation is high on anyone's list of initiatives to improve the world. The resource consumption of Electron is mostly of interest to computer scientists who like to see how small and efficient they can make something. But in this case, it does not really matter.
> The resource consumption of Electron is mostly of interest to computer scientists who like to see how small and efficient they can make something. But in this case, it does not really matter.
It matters to sysadmins. Some people need to also work on the computer and when Teams uses all memory they will close it.
No. It also matters to the users of the laptop and to the people who have to buy it, as using too much RAM can lead to slowness due to swapping and can make older laptops unusable.
It's basically having a third-party forcing programmed obsolescence at your device.
There's also Ripcord https://cancel.fm/ripcord/ which is tiny, native, and works with slack. Going with electron is a simple way to get quick results so companies like it.
Core text chat function has been solid for me the last 2+ years on Ripcord on macos and ubuntu. Image handling, search, notifications, e.g., have varied for Slack and Discord channels.
It looked interesting to me, but their disnhonesty just threw me back:
> Not a subscription—never expires
> Includes 1 year of free version upgrades
Are you telling me that a third-party slack client will keep working forever without updates? The "not a subscription" message here is effectively moot: this thing will stop working and you will need to pay for "another year of version upgrades".
Those are the two common models of proprietary software distribution - subscriptions or one-off payments. Did you actually expect lifetime updates for $20 - i.e. the benefits of subscriptions for the price of one-off purchase?
It's not promising you to work forever without updates, but also it doesn't force you to pay if you're happy and everything still works.
The big difference here is that nobody should expect this app to continue working without updates.
Contrast this with something like sublime text: years from now you can still expect it to work normally.
What I expect is that if your app will not continue working for a long time then you should not make "lifetime license" one of your selling points unless you are prepared to offer lifetime upgrades too.
Performance, small bundle sizes and native UI widgets. And judging by all of the Electron apps failing in these departments, I guess you really do need native apps.
BestBuy sells some Windows laptops with 64 GB eMMC. Space is precious on those. Chrome devices often ship with 16 GB; if Microsoft could make Windows viable at that size, they could push the absolute low end prices down a smidge and keep more users.
I get 60 Mbps down and an upgrade would be $50k. Bandwidth is relatively precious to me.
It's the memory bloat that stands out to me. Many modern laptops have 8GB of RAM. (Curiously this number hasn't really changed in the last 9 years.) 500MB of bloat isn't a trivial fraction of that.
Also, an application that runs constantly in the background, is under a greater obligation to make efficient use of system resources.
> judging by all of the Electron apps failing in these departments, I guess you really do need native apps.
I'd put that differently: solutions heavily based on web technologies seem to consistently fail to be anywhere near as efficient as solutions that use conventional toolkits. (Sometimes someone will suggest this isn't true if the web-based solution is well implemented, but they are never able to give an example of such an application.) On most platforms, Qt doesn't count as being truly native, but it's still far more efficient than Electron.
For me personally, it's having a set of UI widgets as consistent as possible with everything else on the platform as the primary concern. Secondarily it's performance / battery life.
As someone who switches between three platforms, I like that Electron apps are consistent and in sync. Back in the day when I was using Skype, I could never get used to either.
I don't know what Slack or Teams would look like with native UI components, but I am pretty sure I would consider it inferior to what we have at the moment. The possibly improved performance and memory footprint would be nice but not enough for me to care about.
I think this argument used to make sense to me as well, but since most apps I interact with are web apps in browsers these days, most of my interactions aren't with native widgets anyway and I don't really care anymore.
Many of us have been bludgeoned by web apps to the point of not caring any more … most web apps are slow, twitchy interfaces that shift constantly and the industry loves it because it allows them to utilize the armies of (used to be cheap) web developers but at a heavy cost to the user experience
I think this has long stopped being a design goal. The OS is not the primary platform any more which everything orients around, it's an access point to the web. Products are determining design language now.
People don't expect Google to look 'like Windows' just because they're on a Windows OS, they expect Google to look like Material apps across all platforms. There's not 'windows spotify' or 'android spotify' but they expect the app to look the feel the same everywhere, and in that way companies actually benefit from using Electron.
In my experience the people who decide these things talk about branding. Not user expectations. Phone, tablet, and desktop apps have different interfaces anyway. And few people use more than 1 desktop OS and 1 mobile OS
Native is not a tool, nor a goal. Native is an implication of a user experience and performance. Very few non-native applications provide the same experience and performance as native applications (although there are exceptions and it's not always black and white).
"Native" is the implication that a certain level of comformity is present: the user generally gets an experience that is similar to other native applications.
As you develop with native APIs, and when you follow the best practices for the platform, you end up with a product where the UX is much easier to grasp for the user.
Non-native solutions very often have different UI/UX patterns, which leads to users having to learn these patterns before the application becomes understood by them.
> the user generally gets an experience that is similar to other native applications
This sounds like the goal you want to achieve using native as a tool.
But anyone who struggles to grasp non-native UI and UX is going to struggle to interact with the modern IT environment as there is no standard for web-apps.
If I order a cup of tea, you could argue that what I actually want is to achieve the goal of drinking something which has the taste, smell and general nutritional profile of tea.
Theoretically, there might exist a cup of coffee that achieves this goal. But I've never seen one, and if you serve me coffee it's almost certainly not going to achieve my goal.
Native apps means essentially building at least 5 distinct apps: windows, mac, iOS, linux, android. What a mess to work with and maintain.
We already have cross-platfrom UI engines called browsers and they're very advanced and reasonably pleasant to work with these days. If you bundle the browser (electron) then you don't have to worry about differences between browsers. So electron makes plenty of sense to developers, even although it's an egregious resource hog.
Not a great example since they sold over a billion worth of stock. They do actually have more money now.
Microsoft generates more money than they know what to do with so they return large amounts in dividends and probably stock buybacks (I haven't checked for MSFT specifically, but it's all the rage these days.)
Regardless of what the financial markets value them at, their resources are proportional to profits, not market cap.
That aside, they also have lots of products and teams and some have more budget and resources than others.
Saving some memory usage in teams for more than double the development costs, is probably an unattractive position for that team. It also makes it hard to keep features consistent across platforms (as it is, teams struggles with that!)
Share market can double overnight while hiring process will take months. Plus, market valuation increase purely due to the last shares traded between owners of the MSFT shares unless MS themselves participate to raise capital by issuing more shares. Borrowing now is way cheaper as 2T means they cashflow in coming months need to reflect that.
I'm not denying that it's a complex or costly process, just lamenting that they don't care enough. Of course, the problem is compounded for me by the fact that at any given moment I end up having 3 different enterprise chat apps open on my work laptop for collaboration with outside parties.
And the result of that knowledge is a worse experience for users. However you frame it, users are losing because MS doesn’t want to shell out the cash for good UX.
Outlook is switching to WebView2-based UI like this soon. As for Excel, here's its PM saying "When you look at the overall allocation of resources on the team, a huge percentage is working on web app improvements" https://twitter.com/jones206/status/1388162347059978243?s=20
If only Microsoft had a app development framework designed to allow developing apps for multiple mobile + desktop platforms with as much shared code as possible.
Cross-platform development is like communism. An unattainable utopia. There's no "magicking-away" the idiosyncrasies of cross-platform development with abstraction layers. It's simpler to use native tools and go for the best each platform has to offer while keeping the L&F UX as similar as possible.
React Native and (arguably) Flutter are going through a golden age right now. Major companies like Tesla, Coinbase, and Shopify have adopted them, and the developer experience has never been better. I'm not sure why it worked now, but didn't work for Xamarin / Ionic, though.
Popularity means popularity. It doesn't mean utility. There are plenty of dumb things large companies use. OTOH, there are also many unsexy, little-known, ubiquitous technologies essential to certain sectors of the economy.
For Xamarin I would answer that with: Flutter and React native are 'light' on the developer: you get instant feedback. Xamarin, at least when we dropped it 2 years ago, was really slow and, besides c# which we will use on the server, hardly pleasant or light. I think these days, the developer needs a smooth experience (once the tons of crap has been installed and set up, which is why I prefer Flutter over react native) so things that are not that will fall over. I think, after that, comes author influence: so if you take that, you get to RN, Flutter, Xamarin, Ionic if you sort them by EasyOfDev,AuthorInfluence.
I've never used it in anger, but I thought Xamarin probably had the most pragmatic approach. Their recommended path was to have a common core of business logic, but to build native UIs for each platform you wanted to support hooked into that logic.
My SO just finished a term project that used Xamarin.Forms. Conceptually the framework is perfect then you actually use it and want to off yourself. MAUI, if taken seriously and isn't only a rebrand, could be quite an accomplishment and a great tool.
I'm not sure about the state of Xamarin Forms these days, but back when I worked with it a few years ago even the sample apps had memory leaks on iOS. I agree that conceptually it was amazing, as was Xamarin itself. If Forms doesn't have leaks these days it would definitely be a great way to build cross-platform apps.
It's basically rebranded Xamarin Forms. Outside of bundled Windows apps, Microsoft is going all into web technologies for consumer apps now. Even within bundled Windows apps usage of .net is almost nonexistent. Built in OneDrive client is written in Qt!
How can an organisation start a Web/Desktop project which can never ever be _good_ (not to mention great) and frustrate and annoy its customers all the time? If native is a mess, how is outsourcing the mess to the user justified?
What's the alternative? Be only on one platform? Not viable today. Implement 5 different apps, usually not viable.
The platforms are fragmented and the user pays the costs of that in the end, one way or another.
If you hide it by increasing development costs, the price of the app ( or amount of ads or premium only features) must go up to compensate and the user pays the cost as well.
Edit: downvote all you like, there is still no magical solution.
That's a hopelessly simplisitc way of looking at the situation. Every team at Microsoft has different levels of resources, and some would rather spend those resources improving their product rather than writing and maintaining 5 different versions of the frontend part of their product.
Abstract away the core of the product (data, connectivity etc) behind an internal interpreter, which is the same on all platforms and connects to native UI.
When and where it's a priority: creating a solid user-experience takes effort. If a project can't manage that when it matters, then their product or service is also going to suck in so many other ways their users will notice. Then native or not, it won't matter when everyone hates them.
Mac and iOS are relatively-straightforward, aren't terribly different, and share development resources.
Android (Kotlin) doesn't often lead to suicidal ideation.
Windows is meh.
Linux is so-so.
> So electron makes plenty of sense to developers
To mostly front-end developers who don't know much about the world outside of a browser.
> , even although it's an egregious resource hog.
Violating nonfunctional requirements to be usable, performant, and efficient.
> To mostly front-end developers who don't know much about the world outside of a browser.
Just for the record I'm a senior backend developer, who sometimes operates at CTO level in startups, and I suck at front-end development. But still electron makes sense to me. Or react native if it's mobile only.
The state of cross platform development is pretty bad.
It wasn't directed personally. The tendency is for front-end developers (the bulk of developers numerically) to treat software development like RMS does with emacs: everything extends from their perspective without consideration of perspectives or paradigms beyond their own. Embedded, native, real-time/mission-critical/fault-tolerance, resource-constrained, widely-compatible, ASIC/FPGA, and/or production-/shipping-scalable.
Cross-platform development will never be improved by N-times duplicated effort of abstraction layers on-top. The best that could happen is for OS developers to agree on common interfaces like UNIX/The Open Group for low-level operations, but for high-level media, UI, and common native development APIs more integrated than a patchwork of libraries like Qt, LibUV, etc.
I've worked on nuclear reactor simulators in F95, embedded industrial GPS equipment, deadline-oriented ad server meta-mediation, Fortune 500 client-facing consulting, compilers, functional programming projects, and now earn a paycheck doing SRE/PE since it's easy money to fund side-hustles.
We also have Swing in Java which is mature, performant, and works across all our desktop stacks. Mobile UI is different enough that you need to write a different interface anyway.
In other words: outdated, ugly and barely supports modern requirements such as high dpi. Apart from Jetbrains who put in a literal buttload of engineering, there is not a single Java Swing application that is not an absolute PITA to use.
I‘m sorry but have you been living under a rock? SwiftUI, UWP and Jetpack Compose are platforms that differ extremely from the way Swing works. Swing on macOS looks like OS X 10.9 (still uses Lucida Grande as the System Font), we’re 5 releases past that. On Windows, it looks like Vista, we’re past that, too, see modern apps such as the Terminal.
I don't think the inversion of control that SwiftUI or Jetpack Compose do on MVC is particularly fundamental. Factoring out the diffing of state when an observer is notified of updates into a single place can be a useful thing to do in certain cases, such as when a bunch of teams are all putting things on the screen and you don't want one of them to screw up the update loop for everyone (thus Facebook's use of React), but it makes the creation of composable views less straightforward, and you end up with the new problem of annotations to try to keep recalculation of the whole UI from being a performance problem. In MVC, a compound view can usually short circuit updates of its child views very naturally when there are no changes needed.
I just opened a couple of Swing programs on macOS. Other than not having dark mode, I couldn't see any major difference. I can't check it on Windows right now.
I don’t think that connecting the 4 buttons of functionality in 5 frameworks is all that much work, when the bulk of the work is backend. Also, it is a trivially scalable problem, where you can just throw 5x as many people at it.
I get the popularity of electron and other cross-platform tools for small startups, but for Microsoft..
> Also, it is a trivially scalable problem, where you can just throw 5x as many people at it.
Having done exactly this work it's really not as simple as throwing 5x as many people at it.
Though to be clear, I am an advocate of native apps on each platform and am not a fan of "wrap a webview around it" type fake-apps. That said, we need to be honest about level of complexity here.
The problem with maintaining 5x native apps is not just the cost of hiring 5x as many people - as you scale towards more platforms the inter-team coordination overhead increases exponentially.
The complexity of coordinating 4 teams to ship in lockstep on 4 separate platforms isn't double the complexity of 2 teams on 2 platforms.
There are a bunch of intersecting factors here:
- product management has extreme load - new features need to be designed for every supported platform at the same time, increasing complexity in feature definition. Some features aren't possible on some platforms, so that increases scope and complexity of the features as we include fallbacks or exceptions.
- engineering has to happen (roughly) in lockstep with one another. It's not acceptable to ship a new feature only on Windows and not Android - they don't have to launch on the same day, but neither can they launch a year apart. This means you have multiple engineering teams that basically have to move at roughly the same speed, even though they are developing on completely differently platforms.
- underlying platform changes affect your ability to move in lockstep - iOS and Android both have significant yearly updates that create additional testing needs. Both platforms also introduce more significant OS-level features that you want to add support for than the older/more mature platforms like macOS or Windows. This throws another wrench in having your teams progress in unison.
There are real advantages to cross-platform frameworks, even though I dislike them from a UX perspective. In particular I have beef with the use of web views, which while offering incredible consistency between platforms is probably the least CPU/RAM efficient way to do literally anything. A huge part of why computers feel slower than ever is the pervasive use of web views for everything.
I really, really wish we had a better cross-platform solution than a thing with an ill-defined render cycle, bases literally all rendering on an XML-like structure, and has all processing stuck to a single thread on an interpreted language. Yikes.
Maybe mac users need to start paying for app instead of complaining about every app that doesn't use "native toolkits" or doesn't "support the most basic Mac behavior'. There's a reason that they don't, it's that mac users that care about this don't pay enough to justify a native app.
They are the one example of messaging done right on the client side.
And it maddens me that their whole team, including ops and backend is like 50 people.
At the same time, they used some pretty unconventional ways to find brilliant people. For example, for iOS and Mac and android apps, they simply held a contest for the best open source app fitting succinct and reasonable requirements. The winner got sizable prize and place on the dev team.
Then they released that app as a Telegram X and then gradually sunset the older app.
> And it maddens me that their whole team, including ops and backend is like 50 people.
But that's how they get so much accomplished. Fred Brooks was correct in 1975 and is still right in 2021. Throwing headcount at a problem only delays it.
I've never used Telegram, but I suspect the Teams integration with SharePoint/Office365 and the (terrible) way Teams tries to be cake icing and floor wax by integrating file store, wiki, document library, telephone, whiteboard, plugin app ecosystem and webhook scripting environment with Windows ACLs makes it more complex than an independent chat/call/video call program?
Don't get me wrong, I loathe Teams and its laggish bullshit nature as much as the rest of the pitchfork wielding people in this thread, it's just that it's not apples-to-apples comparison with a pure chat/call client and the headcount needed to develop it because of how much extra junk is hiding in Teams.
I agree with your point however it just goes to reinforce that part of the failure of teams is that it kind of does a lot of things but it does all those things really badly. If they had some notion of a product vision, some focus, some opinions and executed on those with a users first attitude then it might not be in such a sorry state and it would probably be a whole lot easier to deliver great native experiences. IMHO a big part of the problem is this idea of just throwing features at applications without designing an actual product that seems to be extremely popular but always dreadful. Do less and deliver excellence, don’t do everything half arsed and throw more adverts at the resulting problem.
Blaming a poor user experience on “being terribly written” seems to be nearly a tautology except that I’m sure there’s been beautifully written software that was otherwise as bad as Vogon poetry.
Teams tries to do a lot of functions. Maybe too much?
My 2015 MacBook, despite being old, is generally just fine for my web development work -- the one notable exception is Teams, it is almost unusably slow for me. I hadn't yet investigated whether it was a RAM/swap issue or other. But it's the only thing I have to regularly use (per employer) that gives me trouble.
I have a top of the line Thinkpad with Windows 10 Pro, 64 GB of RAM and a 6 core Xeon CPU. If it makes you feel any better, Teams is slow and annoying on my machine as well.
Please, no! They would fuck it up somehow, and then abandon it after a few years. Qt has been very stable and dependable for.. ages. MS has created and forgot then forgot too many frameworks during the same time.
A few years back my company put out reqs for Qt devs because we were pushing hard to do some POCs with Qt frameworks. We had a hard time finding those people. I don’t know if it was location or compensation or what.
Unless you need to make a really complicated UI, do you really need Qt devs?
I did a custom widget for editing petri-nets in Qt (no QML), you just need competent devs, whether you have Qt, GTK, or winforms experience doesn't matter.
I'm wondering how swapping Electron for another Chromium backend will allow them to halve the memory usage. Is Node the main reason that Electron uses so much memory? Or is the Chromium renderer poorly optimized to the extent that it's using double the memory needed?
You must remember that each Electron instance will have its own gpu and browser process.
If you do just like Chrome, one host process + one gpu process and all the rest are renderer process as it was meant to, you will use less memory.
Im working on something that are meant to enable native applications with a Chrome-based platform, and it was one of the first thing i've tried to achieve.
Electron was just being sloppy and stick with its first MVP.. because being able to centrally control things through a process like the Chrome browser process does, give you a lot more functionality to explore, compared to what Electron is doing where each host/browser process is isolated and don't know about the other players.
I'd like to see an independent check of this claim, like 50% memory reduction, but under what circumstances?
If that's at startup when the app doesn't consume a huge amount of memory that's not a particularly interesting claim.
If that's after hours of app usage when the previous Electron app used to consume let's say 1GB that's really impressive, but if the app is consuming 1GB of memory it's because the app itself is allocating a huge amount of stuff in the heap, you can't just swap browser engine under the hood and cut that in half with no downsides, otherwise every browser maker would do just that.
> I'd like to see an independent check of this claim, like 50% memory reduction, but under what circumstances?
You have 32 GB RAM ? Teams will use only 16 GB.
> If that's at startup when the app doesn't consume a huge amount of memory that's not a particularly interesting claim.
Of course it's at startup. Then the app needs to draw its ugly black window and it needs more RAM. It uses HW acceleration, you know. And it's slow like hell.
> If that's after hours of app usage when the previous Electron app used to consume let's say 1GB that's really impressive, but if the app is consuming 1GB of memory it's because the app itself is allocating a huge amount of stuff in the heap, you can't just swap browser engine under the hood and cut that in half with no downsides, otherwise every browser maker would do just that.
Every respectable browser will use the whole available memory. From time to time they will have a patch to halve the memory usage but they will recover quickly.
It seems to me that Electron is a scapegoat here - VS Code is built on Electron and is super snappy and responsive for me, even on large projects. This means two things:
1. Even complex Electron apps can be performant and responsive
2. Microsoft as a company has people that know how to make this happen.
The reality is (speaking as a former MSFT employee) that the Teams and VSCode orgs are so far separated that they might as well be in different companies. The average quality of devs and their respective management chains varies WILDLY across organizations, and given how shitty Teams has been and continues to be, I think it's fair to say one or both of these factors is at play here.
Everytime Electron is mentioned, VSC will be presented as counter example. The problem is VSC is the only snappy Electron app out there, Microsoft spend millions optimizing it, while most other Electron apps are crap.
Native programs can be made snappy easily. That's the whole point.
But then with native you have to pay the cross platform price. Which is higher do you think?
With Electron you get cross platform more or less for free and ostensibly you can make it faster later.
Don't get me wrong, I love doing native work, but as someone who has to deal with cross-platform issues in native applications (well games) on the daily, I can tell you that even with massive code reuse and good interfaces, that cost is incredibly high.
I mean, you are talking about making a goddamn text editor faster — it’s just ridiculous. There should be no lag whatsoever when it comes to UIs in 2021.
Building a text editor across platform with exact the same behavior is somewhat a thing that you almost always to redo "everything" in different platforms.
It isn't very unseasonable to just relies on something that already do most hard works for you.
If you must use some "native" alternative. It is probably something like GTK/QT. But I doubt do they actually have the ability to do such complex edit behavior and layouts.
> It is probably something like GTK/QT. But I doubt do they actually have the ability to do such complex edit behavior and layouts.
They actually can - QtCreator for example. Also, I really don't think that the web would be the panacea of UIs, on the contrary.
But I otherwise agree with you - text editors are surprisingly hard. But I still don't really get the why for teams. It could even just add a webview for the actual meeting part, but let the rest be something actually workable.
> But then with native you have to pay the cross platform price. Which is higher do you think?
You could for example use Qt. It is cross-platform and if you write your application well, the amount of platform-specific code will be quite small.
>With Electron you get cross platform more or less for free and ostensibly you can make it faster later.
It's not for-free. The effort/work for the developer is reduced, while the amount of work for the users' PC is increased. Sure, a lot will think, that this is a great deal, but at in my opinion, you should do it the other way round.
How often have you seen electron apps going faster? I never did. With a native toolkit, you have performance from the beginning for the same quality.
> "But then with native you have to pay the cross platform price. Which is higher do you think? With Electron you get cross platform more or less for free"
Don't pay the cross platform price. Stop developing inferior software for your core users so that other people on other platforms can also have inferior software. It's not a good tradeoff, it's a bean-counter's tradeoff.
It's like going to a steak restaurant and finding they only sell lettuce so vegans can eat there, or going to a bar and finding they no longer sell alcohol because they're trying to appeal to tetotallers who don't like bars. It's like Ferrari putting a Honda Civic engine in to try and appeal to both sets of customers and the Honda customers don't want the six figure price tag and the Ferrari customers don't want a low power reliable 4-cylinder engine. It's the "one size fits nobody very well" of software, it's the abandonment of your core competency to appeal to people who hate you.
Visual Studio Code is easily one of the most unresponsive IDEs I have used in a long time. If I edit a big file it just completely seizes up while trying to process it again, and everything feels delayed.
I still use Skype, as Discord is missing a feature I use. With Skype people can call me using a landline and I can dial out to landlines. It would be cool if Discord added VoIP landline support and could even transfer numbers from Skype to Discord.
Client dropped Slack for Teams. I hate it, and information exchange has dropped precipitously since everyone switched. So slow, half the time text markup doesn't work, and the UI is inconsistent depending on if you're typing in a chat, meeting, or channel.
Oh and none of the Slack logs were kept, losing years of information. (But that's not the fault of the Teams software)
I agree with this. Also how can they forget an option to “paste without formatting”? Copying stuff from other sources is extremely painful. At this point, I leave it as is. I don’t have time to micromanage each copy and paste.
Also teams has this arbitrary message character limit that makes it terrible for sharing large chunks of text (partial logs for example).
While the integrations with outlook (mail/scheduling) + teams works “well enough”, the experience of the app itself leaves something to be desired.
For the cases were software or OS doesn’t support native plain text paste I create a similar shortcut in Keyboard Maestro (macOS) or AutoHotKey (Windows).
As an extra measure I configure the macro to automatically type the text and not use the direct clipboard paste. This takes care of the situations were the app prohibited pasting.
Can somebody explain why "paste with formatting" is so widely the default option? I have literally never wanted to paste with formatting and neither have multiple family members who have needed help with preventing it from happening.
All I can figure is that research/observation showed that:
- Normal users often prefer to paste with formatting.
- Normal users will never figure out how to do that if it's not the default.
- Normal users will usually reluctantly accept paste-with-formatting even if it's not what they wanted—that is, it's only rarely entirely unacceptable for them.
- Power users will figure out how to paste without formatting.
You think Microsoft, of Ribbon and Clippy and full-screen start menu ads, and 20 different control panels for the same settings, does UX testing...? The same Microsoft that can't decide whether normal users prefer Windows, Windows Phone, Zune, or Xbox interfaces, so they just go ahead and add a little of each to all of them?
More likely they were just worried Slack was attacking their enterprise segment and killing Skype so they rushed a shitty product to market ASAP. "Embrace, extend, extinguish" has turned into "panic, copycat, repeat".
I imagine it stems from Powerpoint or Word. If I move bolded header text from the bottom of the page to the top of the page, it would be irritating to re-apply formatting. Once you have established this precedent, easy for it to infect the rest of the ecosystem.
IMO if paste with formatting was assigned another shortcut like Ctrl+Shift+V and the default Ctrl+V was without formatting, that would be less frustrating.
I do actually use it all the time. We share some slack channels with external partners but email is the main mode for some others and I have to send code, interfaces, etc on occasion and copy pasting from VS Code maintains the formatting in Apple mail which I’ve found useful. No hitting the space at a hundred times to indent a nested line. And it’s easy enough to escape.
But that behaviour everywhere would drive me nuts.
I think they mean formatting as in slightly different font, color, background or goddamn underline and the like. I have never found it useful, and would be much much better with a non-default right click past as formatted option.
Your use case will not suffer since whitespace is text.
Formatting can hugely change the way text is read. It's quite common for the spacing between sections to be derived from the formatting. So removing the formatting can result in section headings with zero space from the preceeding paragraph but a manual newline between it and the next paragraph. Thus the headings essentially disappear into the preceeding text.
I've had countless other examples over the years where "paste without formatting" involved lots of manual editing of white space. Bullet and numbered lists sometimes vanish which rather matters if the text says "see point 3 above"
The normal case is when you’re cut/copy/pasting intra-app. Imagine if you formatted some text and then cut/paste to move it around and by default you lost your formatting.
Yep, this would be a good reason to keep it. You could probably get around this by using a separate MIME type for your app's content. If that type is present, use it, otherwise default to no formatting.
I'm not sure how intuitive that would be for users, though, having different defaults depending on where the data is coming from.
History. The Mac didn’t have “paste without formatting”, and assigned ⌘-V to “paste with formatting”.
Even if it had, they might have made it the default, either to show of that styles copied over, or for consistency. If you paste a picture, you don’t lose formatting, either (of the picture, whatever that means, or any text in the image)
If you copied some text in MacWrite, for example, exited MacWrote, launched MacPaint, and ⌘V-ed into MacPaint, you likely wanted to keep the font, size and style.
And yet macOS now has paste without formatting in almost every app I can think of (it’s enough that I’d guess it’s a standard thing apps get if they use native frameworks) AND it’s trivial to remap a menu item to another keyboard shortcut across the entire OS.
Most of those are very specific versions of formatting or specialty features.
The only ones that would qualify as "paste without formatting" are "formulas" and "values" modes, and of those two I'd probably say "formulas" is a better default.
Last time I built something on MacOS, this was basically just a feature of the clipboard API that each app could use independently. When copying to the clipboard, you could declare numerous formats for what was copied, and any app receiving clipboard input could state that they only accepted one format.
e.g. copy a jpeg file and you can paste it into Slack, and it will automatically add the image to the post. Paste it into the terminal and you'll get the absolute path to the file. Those sound like sensible defaults that are essentially 'context sensitive paste'.
You could copy a link from a webpage and store both the HTML version and a raw-text version in the clipboard, probably a version that used an annotated string, too.
For the same reason, yeah... this isn't as intuitive when it comes to software like Excel.
That has been around on the Mac since 1984 and applications were always encouraged to put plain text on the clipboard alongside formatted text, but we’re talking UI here, not technology. This kind of UI allows you to choose which of these you want because it turns out the application cannot always make the best choice.
If you sit someone who doesn't know How Links Work in front of some text with an inline hyperlink in it, then try to get them to copy it over to another place, you end up wanting to get to this default pretty quickly. "Right click copy link address" is real unintuitive. I've never wanted the text formatting itself to come over, bold text and headings and whatnot, but since that lives in about the same conceptual space, it's a casualty of design.
It would be pretty trivial to paste without formatting but still auto-parse links. Many apps do the link parsing on the client side, so it's not a formatting concern at all.
That's fine if the text you're copying spells out the URL, but often it will be just a word(s) that are hyperlinked, so if pasted as plain text the software you paste into has no idea there was a URL linked at all.
(But I too wish plain text pasting was the default more often.)
How would that work in the case where the link display text is not the address? Normally pasting without formatting discards the fact that some text like “download other file” is a link.
>Also how can they forget an option to “paste without formatting”
That's just Microsoft.
I can probably count on one hand the amount of times I've wanted to actually retain source formatting. But, it's the default option on almost any microsoft product out there. And, apparently, on Teams it's not an option at all.
Ctrl+shift V... How about where's reply to a specific message on a desktop/web app? Isn't that like the basest of the basics? Audio and video quality is great however, millions of times ahead of Slack and a bit better than Zoom, but ever so slightly, from my experience.
Nothing is more painful than to watch others copy and paste complex linux commands from Teams into the terminal, and watch the shell get corrupted. Windows copy and paste has always been a mess for me. macOS seems to do it much better, but X11 middle click is the best.
FYI, Ctrl+Shift+V works as a paste without formatting shortcut in Teams. But for some reason I can't work out, they chose not to put it in the right-click UI.
We were using Skype for Business before and Teams was a big improvement over that. It does video conferencing and file sharing well, with even collaborative editing of Office files working well. The chat features seem like an afterthought so if you're comparing it based on that I'm not surprised it's that bad.
As one "for example", that's the product team that couldn't figure out how to stop repeating AD logins with invalid saved passwords for 5+ years. Which invariably led to a system you were signed into somewhere locking your account every password rotation.
An extremely low bar, it was incredibly poor software. The Teams migration was great compared to that, even for messaging.
For VC and file collaboration Teams seems good in absolute, for messaging it seems good only relative to that. Messaging feels like a third-priority feature in Teams. If you're coming from a good messaging experience and that's what you mostly use Teams for then it's no doubt a really poor experience.
While Slack displays all your organizations in a single tabbed UI, presenting you with the number of unread messages on the tab icons in Teams you need to hard switch and you never know what happens in the others. This makes Teams worse than nothing in communications because one half of the communication expects you to communicate and you are not even aware of this. You literally must jump organizations constantly , possibly needing to log in too, just to see who is pinging you.
Right! My company switched from Slack to Teams and even though we recreated all our original channels, public discussion has all but died. Having to context switch between private messaging and public channels, even though it's just another tab, is apparently just too much friction.
Also opening docs and excel sheets inside the main window by default and blocking chat while doing it is absolutely atrocious.
Swtiching windows in teams is slow, 20 years ago Microsoft knew the research on this and minimum viable response time. They ignore it and the predictable result is people don't take advantage of teams. It possibly could be good, but I want Skype back, it didn't do as much, but what it did it did well.
It's an asinine primitive mapping, that could only come from a project manager who spent their entire career optimizing SharePoint access controls to meet HR product requests.
The entire point of modern chat solutions is persistence and searchability. So the only real differentiation should be public or private channels.
You can't even read stuff from other tenants if you are in a video call. Teams came for free at a lot companies I worked with and all of them have moved back to Slack and many of them are also paying for it.
My favorite about video calls is at one of my organizations I am access denied to recordings even when I participated in it. I can't attach images either.
Someone built these features. Why are you building a feature on who can attach images?? The entire mindset is completely wrong and comes from an overcontrolling enterprise mindset completely incompatible with what we expect from a chat tool.
Oh and every time I log in Teams asks whether it can control my entire device. No.
Good it asks though. So many stupid apps like Instagram and so on that assumes that the logged on user owns the device. In Europe it is very common that you are provided with a device from your work place that you also use in private. I did a password reset on Instagram with such a device. Totally unexceptable.
Our company (we'll call it Monsarno) was bought by a certain German aspirin company, and our Bavarian overlords are slowly forcing us from Slack over to Teams. It's a nightmare, and very few groups have made the transition willingly.
My team started off piloting a self hosted Mattermost instance used by our developers and quality assurance testers. Tons of information exchange as well a team bonding.
Then they rolled out Teams for the whole company. We lost a ton of features that made Mattermost a delight to use. The way channels worked felt less intuitive, and it was just harder to care about group messages. And the worst part? A 30 day deletion policy.
Even without the deletion policy, searching only brings up matching messages without the context and scrolling back takes ages (and jumps to the present from time to time).
Same for us. Our channels went from vibrant to dead in a week because notifications are somehow broken there in ways I can't explain.
The solution for us was to create multi-user chats in the "Chat" section and let the "Teams" section die the horrible death it deserves.
The notifications are more consistent in "Chat". But god forbid someone talks too much, because then you get those horrible non-native notifications that are completely broken in itself too.
It's probably the worst app I've used in years, and that's saying a lot because app quality is incredibly bad these days.
“Microsoft Silverlight will reach the end of support on October 12, 2021. Silverlight development framework is currently only supported on Internet Explorer 10 and Internet Explorer 11, with support for Internet Explorer 10 ending on January 31, 2020. There is no longer support for Chrome, Firefox, or any browser using the Mac operating system.”
> If not even Microsoft itself writes native code for their own bloody OS then we're just doomed
I agree a native client would be great, although I assume this choice is more because Microsoft wanted it to be multi-platform across iOS, Android, Web, Mac, Linux, Windows, Chromebook e.t.c. and that would either require building it multiple times, or building it in html/js as the lowest common denominator (web).
My last job used Teams after I had years of experience with Slack and I’m right there with you. I actually enjoy being on Slack and feel like it adds something to the workplace culture (although yes, as many have pointed out before on HN, not everything Slack/real-time team software adds is good). Custom emojis in particular, such a simple thing and yet they really build a channel’s culture. Slack feels fun. Contrast that with Teams, which just feels soulless and corporate and… “angular” is the word that comes to mind. Obviously they are both run for profit, by corporations, for work, but the feel is indescribably different to me. Super grateful my current job uses Slack.
I worked at a game company that was moving from google enterprise (gmail, docs, etc) to office be use our owner organization used office. Everyone fought hard to keep slack because teams is so bad. We got to keep slack but had to adopt office and it was a disaster. Outlook web and app act completely different, the mail web and app act completely different. the way to edit and share files was very confusing and always had permission issues. We were told we’d keep our email history, then the last 2 years of our history, and then finally they were unable to migrate the history and we lost years of emails. It messed the company up so much, I’m sure it’s one of the contributing factors for why the company was closed 6 months later. Like we were at the end of a 2 year development process going into soft launch, but this migration crippled production and the parent company never took responsibility.
On the contrary, I find that the total suckage of Teams means that there is no random chatter in Teams like we had in Slack because people hate using it. No memes or other random stuff. I like it.
My 2cts with teams. Multiple clients use teams and sent me invites with team links.
There seems to be no way to open or see the meetings directly within team. I always have to open my mail, click the link, go to the website, click on open in teams and only then will it open the meeting.
We use Teams at my University. Generally if something University-sponsored outside of the college of engineering wants to make a chat about something, they use Teams. CoE uses Discord, fortunately.
Easily my least favorite chat app, save for those that break basic functionality as their core product (Snapchat). Teams doesn't seem to understand that organization admins might want to see user names in a different format than users. Everyone's name is Last, F., which makes sense from an administrative standpoint but needing to click into someone's profile to figure out who they are gets old _very_ fast.
The only selling point that Teams seems to have is "we're already paying for it."
It's user interface is unintuitive and messy. I find it difficult to find the context I want.
Search doesn't seem to work.
It takes a long time to load.
When it eventually loads, it pops itself up in front of whatever I've opened and started working on (whilst Teams is busy loading) to take all my keystrokes until I notice the keystrokes aren't showing up in the program I was already using - I've seen at least one person's password entered into a chat session because of Teams "grabbing the front".
And, finally, Teams has taken the initiative to redefine "full screen" such that even that unambiguous terminology is now meaningless. Full screen now means "zoom in, just a little bit". Fuck you Teams.
Screen sharing / video conferencing works fine, however. Except the full screen thing, so even the decent bit has a large caveat.
My apologies for the outburst, but I had to get it off my chest. Teams fucking sucks.
I started writing a long-winded thing to enumerate the problems with Teams that no product person at Microsoft will ever see, so why bother? It's a terrible product. The purported sticker price for enterprises disguises the costly loss of productivity due to this mess. It's just a godawful mess.
Audio mixing is poor compared with Zoom, any background noise on an active microphone will cut out another person speaking.
The controls menu keeps changing. Click on the "raise hand" icon and it disappears, you can't "lower your hand" until it reappears some random time later.
Why is it that in every one of these meeting apps, speaking causes them to totally garble any other person speaking simultaneously? It's like they go "oh you are speaking lets downgrade all others to 1kbit/s". Stop with the byte pinching and just give us the full fidelity sound like I'm using TeamSpeak, it's fricking audio.
I think it's because of echo cancelling technology. In software like discord you can disable it and it's way better when people are talking simultaneously.
I haven't worked on a search product, but I've worked at small shops with bad search products (one's business was even that product).
Search is hard when you don't have lots of training data, data is poorly organized, you have mostly tail queries, and people aren't used to you search engine's quirks. Search results are also bad when you're balancing quality with yield (as in revenue).
Google mostly doesn't have these problems. It has loads of people searching for head queries, so results are continuously being tested to death. Website owners put some effort into making their content accessible to Google with SEO, and people are used to searching with Google, so they've learned a few tricks for less popular queries.
Local search and corporate intranet search have none of that. You're basically whatever Lucene does out-of-the-box.
Electron and Edge Webview2 are basically the same: they both wrap Chromium in the end, possibly with some downstream changes. So this is primarily a branding exercise, and maybe and admission that Microsoft isn't upstreaming some improvements to Chromium.
I had this issue with Teams where if I pasted code from VSCode (even just a 1 liner) it'd add a NUL character to the end and when pasted back into VSCode by the recipient it would mess up the JS file (no longer able to load properly in a web-browser).
Just don't understand how MS can mess up simple copy+paste so badly.
Tools like Slack and Teams are focus-killers and should be banned from all companies that want to work efficiently. The synchronous nature of these tools and the chatty blather they encourage should be avoided by all serious knowledge workers.
Simple … email … I choose when/if I will respond on a schedule that I define and My response can be more complete therefore avoiding many of the roundtrips that these tools support and encourage. If someone needs a meeting, they can schedule a meeting from open time that I have provided in my schedule that is shared to my team.
The "chatty blather" is a culture 'problem' (assuming you see it as a problem), not a tools problem. Where I'm working now we only have channels directly connected to specific projects and only people working on those projects are on those channels, and there is no project irrelevant chatter happening. There are no company wide channels and no 'off topic' channels so very little social banter takes place on Slack or Teams.
Personally I think the problem is over-rated and wouldn't mind if there was a bit more off topic chat going on in our Slack/Teams.
What is the purpose of the tool then? What improvement does it have over email?
The main problem that I have with these tools is the increased number of distractions. There is an expectation when using a chat tool that someone will respond promptly, but this rarely is useful for the person that’s receiving the question.
For most knowledge workers, frequent distractions come at a very high cost. Notions that we are good at multitasking are completely false. Encouraging the use of these tools is contrary to the goals of deep intelligent work And in fact can encourage poor planning and time management.
One is that everything gets sorted under the right project subheading. Discussions about Project FooBar end up in a different channel than discussions about Project Blork. The second is that I can just post on the Blork channel and know that everybody currently connected to project Blork will see it. Equally if I'm not actively working on FooBar I can easily ignore everything connected to FooBar, and just scan through what's happening every other day or so. I personally feel it's useful keep an eye on what is happening in projects tangentially related to what I'm working on without being CC:d on every project related email sent, and Slack makes that easy.
Of course all this can be replicated with mailing lists, email filtering, and decent threading support in your mail client, and perhaps that might even be better, but for whatever reason the tools for easily doing this aren't really being pushed. I'm sure you could build some sort of tools on top of email that gives you most of the benefits of Slack but with a slightly less synchronous feel.
There were tools called bulletin boards or wikis created decades ago that can accomplish what is described above. All of these chatty tools require discipline by those making posts to not refer to other projects within the silo of the channel. I’ve found this to almost never happen. Email allows for normal conversational encompassing communication method that does not rely upon siloing information about projects into their respective channels.
For example, if Blork and FooBar Projects are related In a comment that is made in one of the project channels, it is not easy to navigate their relationships in these tools Without explicitly adding tags to refer to the other channels. All these tags then create a spiderweb of useless links for the most part, and the information flow is weird and difficult to follow in many cases. This model can be advantageous for example when referencing checkins or other tickets within comments of a bug/story reporting system. However, bug reporting systems typically have fewer parties involved in the comments, so things don’t get quite as out of hand.
There were tools called bulletin boards or wikis created decades ago that can accomplish what is described above.
Far be it for me to defend Teams, but one thing it does kind of right is to automatically create a wiki, a project tracking and a file share page in addition to the chat space for each project so that you can, if you want, use the right tool for the job.
That being said I worked at places a decade ago that tried to do the internal bulletin and wiki thing for their projects, and for whatever reason, it never worked anywhere near as well as I've seen Slack work. So while I agree in theory with many of the complaint levied against Slack as a productivity tool, in practice I've yet to see anything work better. But it is also clear that, for whatever reason, I haven't experience many of the time wasting antics that other people seem to be describing.
Teams is an embarassing piece of software. I use it on work laptop - a Microsoft surface. The laptop is Microsoft branded and all their software is so slow. Clicking to change chats is 1-2 seconds of delay. Opening office files is 1-2 seconds of delay. Opening calendar in outlook is 1-2 seconds of delay. Everything is so laggy and 90% of the time all you want to see is text. Ctrl-F search through Teams defaults to non-exact search.
In fact I once timed getting into a Teams meeting from turning the computer on and it took pretty much exactly 5 minutes. FIVE MINUTES. The laptop has an SSD how is it five minutes?
I've recently switched to the browser based client https://teams.microsoft.com and ditched their desktop application as I grew frustrated with its extremely slow UI. The browser client is more responsive, consumes less CPU and RAM, and uBlock some of the tracking javascript.
I can live with some of the missing features:
No noise cancellation
Audio devices are configured via windows sound settings
Can only share full screens and not individual windows
Standard Windows notification sounds and not the Teams sounds.
Maybe missing more otherwise its more or less the same app.
I've installed it as a Chrome App and it has its own window, task bar icon / shortcut and generates notifications.
Thanks for this! Looks to be a game changer for my productivity and sanity!
I was about to get a second device for teams. Performance has degraded so badly that it's now impossible to pretend to be in a meeting and run an IDE / office apps / factorio at the same time.
> Can only share full screens and not individual windows
At least on Chrome, the Teams screen sharing option summons the Chrome screen sharing dialog, which allows you to select either the whole desktop, individual windows or specific tabs inside the browser. Maybe the limitation is from the browser you are using? (Although I would be very surprised)
The delays in Teams kill me inside. I press the up arrow to fix an error, wait for editor to initialize, then wait for the cursor to move to the end of the text, then edit the typo and re-send. The waiting part is 500-1500 ms. The overall responsiveness is abysmal.
358 comments
[ 5.3 ms ] story [ 304 ms ] threadNope, Edge WebView2 is Windows-only. Unless the memory improvements are not actually tied to Electron, but rather Teams 1.0 having a shit codebase.
https://docs.microsoft.com/en-us/microsoft-edge/webview2/#su...
Linux looks like it won't happen until 2022 but Mac is first. I'd guess they are aiming to have it release around the same time as a bunch of other stuff this Fall but still can't commit to that date yet.
Regardless it'll be coming to Mac.
Maybe people will stop sending me zoom invites.
This is about 8-10 times heavier than the Skype for Business client was.
WebView2 looks to be a great choice instead of Electron, now that they're shipping Edgeium everywhere. The old IE WebBrowser control has been a non-starter for a while.
Can we stop using document formatting as applications? We're also not using Word with OLE/COM/ActiveX objects to do video conferencing.
It matters to sysadmins. Some people need to also work on the computer and when Teams uses all memory they will close it.
It's basically having a third-party forcing programmed obsolescence at your device.
would call it more than just an "improvement", only using 1/2 memory is pretty freakin great when you're already known for hogging mem
> Not a subscription—never expires
> Includes 1 year of free version upgrades
Are you telling me that a third-party slack client will keep working forever without updates? The "not a subscription" message here is effectively moot: this thing will stop working and you will need to pay for "another year of version upgrades".
It's not promising you to work forever without updates, but also it doesn't force you to pay if you're happy and everything still works.
Contrast this with something like sublime text: years from now you can still expect it to work normally.
What I expect is that if your app will not continue working for a long time then you should not make "lifetime license" one of your selling points unless you are prepared to offer lifetime upgrades too.
But why?
'Native' is a tool, not a goal, surely?
What's the underlying goal you want to achieve, and do you really need native to achieve that?
Performance, small bundle sizes and native UI widgets. And judging by all of the Electron apps failing in these departments, I guess you really do need native apps.
Space are not precious anymore. Nor is bandwidth.
I get 60 Mbps down and an upgrade would be $50k. Bandwidth is relatively precious to me.
I would suggest that people are likely not attempting to use enterprise-grade collaboration software on these machines, so that's not a problem.
https://www.theverge.com/2021/5/17/22439924/microsoft-teams-...
Also, an application that runs constantly in the background, is under a greater obligation to make efficient use of system resources.
> judging by all of the Electron apps failing in these departments, I guess you really do need native apps.
I'd put that differently: solutions heavily based on web technologies seem to consistently fail to be anywhere near as efficient as solutions that use conventional toolkits. (Sometimes someone will suggest this isn't true if the web-based solution is well implemented, but they are never able to give an example of such an application.) On most platforms, Qt doesn't count as being truly native, but it's still far more efficient than Electron.
I don't know what Slack or Teams would look like with native UI components, but I am pretty sure I would consider it inferior to what we have at the moment. The possibly improved performance and memory footprint would be nice but not enough for me to care about.
People don't expect Google to look 'like Windows' just because they're on a Windows OS, they expect Google to look like Material apps across all platforms. There's not 'windows spotify' or 'android spotify' but they expect the app to look the feel the same everywhere, and in that way companies actually benefit from using Electron.
"Native" is the implication that a certain level of comformity is present: the user generally gets an experience that is similar to other native applications.
As you develop with native APIs, and when you follow the best practices for the platform, you end up with a product where the UX is much easier to grasp for the user. Non-native solutions very often have different UI/UX patterns, which leads to users having to learn these patterns before the application becomes understood by them.
This sounds like the goal you want to achieve using native as a tool.
But anyone who struggles to grasp non-native UI and UX is going to struggle to interact with the modern IT environment as there is no standard for web-apps.
Theoretically, there might exist a cup of coffee that achieves this goal. But I've never seen one, and if you serve me coffee it's almost certainly not going to achieve my goal.
Responds to user input quickly enough to not be frustrating.
We already have cross-platfrom UI engines called browsers and they're very advanced and reasonably pleasant to work with these days. If you bundle the browser (electron) then you don't have to worry about differences between browsers. So electron makes plenty of sense to developers, even although it's an egregious resource hog.
For example... Gamestop's market cap did this recently - https://www.macrotrends.net/stocks/charts/GME/gamestop/marke... - the company doesn't suddenly have more money to spend on projects.
Microsoft generates more money than they know what to do with so they return large amounts in dividends and probably stock buybacks (I haven't checked for MSFT specifically, but it's all the rage these days.)
That's essentially the opposite of what GME did.
That aside, they also have lots of products and teams and some have more budget and resources than others.
Saving some memory usage in teams for more than double the development costs, is probably an unattractive position for that team. It also makes it hard to keep features consistent across platforms (as it is, teams struggles with that!)
- DOS 4.0
- Microsoft Bob
- Windows ME
- Windows Vista
- JScript
- MSJVM
- Zune
- Eliminating all/most easter eggs
https://www.infoworld.com/article/2612971/microsoft-s-13-wor...
You can make many, many mistakes as a giant company, so long as they're not fatal. ;-)
https://dotnet.microsoft.com/apps/xamarin
The platforms are fragmented and the user pays the costs of that in the end, one way or another.
If you hide it by increasing development costs, the price of the app ( or amount of ads or premium only features) must go up to compensate and the user pays the cost as well.
Edit: downvote all you like, there is still no magical solution.
That's typically the smart choice.
Why are we pretending in this thread that there aren't any cross-platform toolkits?
Using that is an entirely valid trade-off between "putting a webshit in its window" and "you have to develop 10 separate native apps".
Those are pretty sucky by comparison to both web and native and they don't feel native.
The problem is not that cross platform toolkits don't exist, it's that they're aren't any good enough.
Also why are we pretending in this thread that it's impossible to write electron or web apps with more reasonable memory usage? Look at vscode.
Electron, as much as I hate to say it, is one of the best options available.
It must be very hard to write Electron apps with more reasonable memory usage if VS Code is the sole example anyone ever has.
Sublime Text is my reference for reasonable memory usage and performance. VS Code doesn't measure up.
I'm not aware of any cross-platform toolkit that works on windows, mac, linux and the web aside from, well, a browser.
> Using that is an entirely valid trade-off between "putting a webshit in its window" and "you have to develop 10 separate native apps".
People don't want to pay the cost of native apps, they want to be able to use apps everywhere and have new features often.
Mac and iOS are relatively-straightforward, aren't terribly different, and share development resources.
Android (Kotlin) doesn't often lead to suicidal ideation.
Windows is meh.
Linux is so-so.
> So electron makes plenty of sense to developers
To mostly front-end developers who don't know much about the world outside of a browser.
> , even although it's an egregious resource hog.
Violating nonfunctional requirements to be usable, performant, and efficient.
Just for the record I'm a senior backend developer, who sometimes operates at CTO level in startups, and I suck at front-end development. But still electron makes sense to me. Or react native if it's mobile only.
The state of cross platform development is pretty bad.
Cross-platform development will never be improved by N-times duplicated effort of abstraction layers on-top. The best that could happen is for OS developers to agree on common interfaces like UNIX/The Open Group for low-level operations, but for high-level media, UI, and common native development APIs more integrated than a patchwork of libraries like Qt, LibUV, etc.
I've worked on nuclear reactor simulators in F95, embedded industrial GPS equipment, deadline-oriented ad server meta-mediation, Fortune 500 client-facing consulting, compilers, functional programming projects, and now earn a paycheck doing SRE/PE since it's easy money to fund side-hustles.
Someday we compile to WASM and have UI rendering on top of WebGPU?
https://github.com/WebAssembly/design/issues/273
I just opened a couple of Swing programs on macOS. Other than not having dark mode, I couldn't see any major difference. I can't check it on Windows right now.
So, no, I don't live under a rock.
I get the popularity of electron and other cross-platform tools for small startups, but for Microsoft..
Having done exactly this work it's really not as simple as throwing 5x as many people at it.
Though to be clear, I am an advocate of native apps on each platform and am not a fan of "wrap a webview around it" type fake-apps. That said, we need to be honest about level of complexity here.
The problem with maintaining 5x native apps is not just the cost of hiring 5x as many people - as you scale towards more platforms the inter-team coordination overhead increases exponentially.
The complexity of coordinating 4 teams to ship in lockstep on 4 separate platforms isn't double the complexity of 2 teams on 2 platforms.
There are a bunch of intersecting factors here:
- product management has extreme load - new features need to be designed for every supported platform at the same time, increasing complexity in feature definition. Some features aren't possible on some platforms, so that increases scope and complexity of the features as we include fallbacks or exceptions.
- engineering has to happen (roughly) in lockstep with one another. It's not acceptable to ship a new feature only on Windows and not Android - they don't have to launch on the same day, but neither can they launch a year apart. This means you have multiple engineering teams that basically have to move at roughly the same speed, even though they are developing on completely differently platforms.
- underlying platform changes affect your ability to move in lockstep - iOS and Android both have significant yearly updates that create additional testing needs. Both platforms also introduce more significant OS-level features that you want to add support for than the older/more mature platforms like macOS or Windows. This throws another wrench in having your teams progress in unison.
There are real advantages to cross-platform frameworks, even though I dislike them from a UX perspective. In particular I have beef with the use of web views, which while offering incredible consistency between platforms is probably the least CPU/RAM efficient way to do literally anything. A huge part of why computers feel slower than ever is the pervasive use of web views for everything.
I really, really wish we had a better cross-platform solution than a thing with an ill-defined render cycle, bases literally all rendering on an XML-like structure, and has all processing stuck to a single thread on an interpreted language. Yikes.
And it maddens me that their whole team, including ops and backend is like 50 people.
At the same time, they used some pretty unconventional ways to find brilliant people. For example, for iOS and Mac and android apps, they simply held a contest for the best open source app fitting succinct and reasonable requirements. The winner got sizable prize and place on the dev team.
Then they released that app as a Telegram X and then gradually sunset the older app.
Pretty neat on multiple fronts.
But that's how they get so much accomplished. Fred Brooks was correct in 1975 and is still right in 2021. Throwing headcount at a problem only delays it.
That's a huge understatement. When development tools improve and people get more productive, that observation gets more and more correct.
Thus, he is much more correct now than he was in 1975. And he was pretty much right by that time.
Don't get me wrong, I loathe Teams and its laggish bullshit nature as much as the rest of the pitchfork wielding people in this thread, it's just that it's not apples-to-apples comparison with a pure chat/call client and the headcount needed to develop it because of how much extra junk is hiding in Teams.
Teams tries to do a lot of functions. Maybe too much?
My 2015 MacBook, despite being old, is generally just fine for my web development work -- the one notable exception is Teams, it is almost unusably slow for me. I hadn't yet investigated whether it was a RAM/swap issue or other. But it's the only thing I have to regularly use (per employer) that gives me trouble.
Teams is basically unusable except making or answering a call.
I did a custom widget for editing petri-nets in Qt (no QML), you just need competent devs, whether you have Qt, GTK, or winforms experience doesn't matter.
https://forum.qt.io/topic/87898/microsoft-onedrive-sync-uses...
If you do just like Chrome, one host process + one gpu process and all the rest are renderer process as it was meant to, you will use less memory.
Im working on something that are meant to enable native applications with a Chrome-based platform, and it was one of the first thing i've tried to achieve.
Electron was just being sloppy and stick with its first MVP.. because being able to centrally control things through a process like the Chrome browser process does, give you a lot more functionality to explore, compared to what Electron is doing where each host/browser process is isolated and don't know about the other players.
Its akin to use a cannon to kill a fly..
If that's at startup when the app doesn't consume a huge amount of memory that's not a particularly interesting claim.
If that's after hours of app usage when the previous Electron app used to consume let's say 1GB that's really impressive, but if the app is consuming 1GB of memory it's because the app itself is allocating a huge amount of stuff in the heap, you can't just swap browser engine under the hood and cut that in half with no downsides, otherwise every browser maker would do just that.
You have 32 GB RAM ? Teams will use only 16 GB.
> If that's at startup when the app doesn't consume a huge amount of memory that's not a particularly interesting claim.
Of course it's at startup. Then the app needs to draw its ugly black window and it needs more RAM. It uses HW acceleration, you know. And it's slow like hell.
> If that's after hours of app usage when the previous Electron app used to consume let's say 1GB that's really impressive, but if the app is consuming 1GB of memory it's because the app itself is allocating a huge amount of stuff in the heap, you can't just swap browser engine under the hood and cut that in half with no downsides, otherwise every browser maker would do just that.
Every respectable browser will use the whole available memory. From time to time they will have a patch to halve the memory usage but they will recover quickly.
I only know a couple of people who like it and I definitely don't value their input since we disagree on pretty much everything
I know Discord is supposed to be for gamers but I've only used it for work and it's hands down the best thing out there
1. Even complex Electron apps can be performant and responsive
2. Microsoft as a company has people that know how to make this happen.
The reality is (speaking as a former MSFT employee) that the Teams and VSCode orgs are so far separated that they might as well be in different companies. The average quality of devs and their respective management chains varies WILDLY across organizations, and given how shitty Teams has been and continues to be, I think it's fair to say one or both of these factors is at play here.
Native programs can be made snappy easily. That's the whole point.
With Electron you get cross platform more or less for free and ostensibly you can make it faster later.
Don't get me wrong, I love doing native work, but as someone who has to deal with cross-platform issues in native applications (well games) on the daily, I can tell you that even with massive code reuse and good interfaces, that cost is incredibly high.
It isn't very unseasonable to just relies on something that already do most hard works for you.
If you must use some "native" alternative. It is probably something like GTK/QT. But I doubt do they actually have the ability to do such complex edit behavior and layouts.
They actually can - QtCreator for example. Also, I really don't think that the web would be the panacea of UIs, on the contrary.
But I otherwise agree with you - text editors are surprisingly hard. But I still don't really get the why for teams. It could even just add a webview for the actual meeting part, but let the rest be something actually workable.
You could for example use Qt. It is cross-platform and if you write your application well, the amount of platform-specific code will be quite small.
>With Electron you get cross platform more or less for free and ostensibly you can make it faster later.
It's not for-free. The effort/work for the developer is reduced, while the amount of work for the users' PC is increased. Sure, a lot will think, that this is a great deal, but at in my opinion, you should do it the other way round.
How often have you seen electron apps going faster? I never did. With a native toolkit, you have performance from the beginning for the same quality.
Don't pay the cross platform price. Stop developing inferior software for your core users so that other people on other platforms can also have inferior software. It's not a good tradeoff, it's a bean-counter's tradeoff.
It's like going to a steak restaurant and finding they only sell lettuce so vegans can eat there, or going to a bar and finding they no longer sell alcohol because they're trying to appeal to tetotallers who don't like bars. It's like Ferrari putting a Honda Civic engine in to try and appeal to both sets of customers and the Honda customers don't want the six figure price tag and the Ferrari customers don't want a low power reliable 4-cylinder engine. It's the "one size fits nobody very well" of software, it's the abandonment of your core competency to appeal to people who hate you.
Client dropped Slack for Teams. I hate it, and information exchange has dropped precipitously since everyone switched. So slow, half the time text markup doesn't work, and the UI is inconsistent depending on if you're typing in a chat, meeting, or channel.
Oh and none of the Slack logs were kept, losing years of information. (But that's not the fault of the Teams software)
I loathe Teams.
Also teams has this arbitrary message character limit that makes it terrible for sharing large chunks of text (partial logs for example).
While the integrations with outlook (mail/scheduling) + teams works “well enough”, the experience of the app itself leaves something to be desired.
Definitely a helpful shortcut!
https://www.makeuseof.com/tag/copy-paste-text-without-format...
As an extra measure I configure the macro to automatically type the text and not use the direct clipboard paste. This takes care of the situations were the app prohibited pasting.
- Normal users often prefer to paste with formatting.
- Normal users will never figure out how to do that if it's not the default.
- Normal users will usually reluctantly accept paste-with-formatting even if it's not what they wanted—that is, it's only rarely entirely unacceptable for them.
- Power users will figure out how to paste without formatting.
More likely they were just worried Slack was attacking their enterprise segment and killing Skype so they rushed a shitty product to market ASAP. "Embrace, extend, extinguish" has turned into "panic, copycat, repeat".
But that behaviour everywhere would drive me nuts.
Your use case will not suffer since whitespace is text.
I've had countless other examples over the years where "paste without formatting" involved lots of manual editing of white space. Bullet and numbered lists sometimes vanish which rather matters if the text says "see point 3 above"
I'm not sure how intuitive that would be for users, though, having different defaults depending on where the data is coming from.
Even if it had, they might have made it the default, either to show of that styles copied over, or for consistency. If you paste a picture, you don’t lose formatting, either (of the picture, whatever that means, or any text in the image)
If you copied some text in MacWrite, for example, exited MacWrote, launched MacPaint, and ⌘V-ed into MacPaint, you likely wanted to keep the font, size and style.
Some programs also have several variants of “without formatting”. Excel is a good example (https://support.microsoft.com/en-us/office/paste-options-8ea...). Which one should be the default?
Most of those are very specific versions of formatting or specialty features.
The only ones that would qualify as "paste without formatting" are "formulas" and "values" modes, and of those two I'd probably say "formulas" is a better default.
e.g. copy a jpeg file and you can paste it into Slack, and it will automatically add the image to the post. Paste it into the terminal and you'll get the absolute path to the file. Those sound like sensible defaults that are essentially 'context sensitive paste'.
You could copy a link from a webpage and store both the HTML version and a raw-text version in the clipboard, probably a version that used an annotated string, too.
For the same reason, yeah... this isn't as intuitive when it comes to software like Excel.
(But I too wish plain text pasting was the default more often.)
That's just Microsoft.
I can probably count on one hand the amount of times I've wanted to actually retain source formatting. But, it's the default option on almost any microsoft product out there. And, apparently, on Teams it's not an option at all.
https://stevemiller.net/puretext/
Agree with your sentiment except that it's not Teams fault that your client didn't care about message history when they decided to migrate to Teams.
So you mean the Lync codebase.
That's a pretty low bar to start with.
As one "for example", that's the product team that couldn't figure out how to stop repeating AD logins with invalid saved passwords for 5+ years. Which invariably led to a system you were signed into somewhere locking your account every password rotation.
For VC and file collaboration Teams seems good in absolute, for messaging it seems good only relative to that. Messaging feels like a third-priority feature in Teams. If you're coming from a good messaging experience and that's what you mostly use Teams for then it's no doubt a really poor experience.
This has been known since 2016 at least https://microsoftteams.uservoice.com/forums/555103-public/su... "Support for multiple work accounts is still being worked on and will come at a later date."
Also opening docs and excel sheets inside the main window by default and blocking chat while doing it is absolutely atrocious.
This is the root of all Teams fuckups.
It's an asinine primitive mapping, that could only come from a project manager who spent their entire career optimizing SharePoint access controls to meet HR product requests.
The entire point of modern chat solutions is persistence and searchability. So the only real differentiation should be public or private channels.
Someone built these features. Why are you building a feature on who can attach images?? The entire mindset is completely wrong and comes from an overcontrolling enterprise mindset completely incompatible with what we expect from a chat tool.
Oh and every time I log in Teams asks whether it can control my entire device. No.
Our company (we'll call it Monsarno) was bought by a certain German aspirin company, and our Bavarian overlords are slowly forcing us from Slack over to Teams. It's a nightmare, and very few groups have made the transition willingly.
Then they rolled out Teams for the whole company. We lost a ton of features that made Mattermost a delight to use. The way channels worked felt less intuitive, and it was just harder to care about group messages. And the worst part? A 30 day deletion policy.
The solution for us was to create multi-user chats in the "Chat" section and let the "Teams" section die the horrible death it deserves.
The notifications are more consistent in "Chat". But god forbid someone talks too much, because then you get those horrible non-native notifications that are completely broken in itself too.
It's probably the worst app I've used in years, and that's saying a lot because app quality is incredibly bad these days.
If not even Microsoft itself writes native code for their own bloody OS then we're just doomed. It's just all so sluggish.
https://support.microsoft.com/en-us/windows/silverlight-end-...:
“Microsoft Silverlight will reach the end of support on October 12, 2021. Silverlight development framework is currently only supported on Internet Explorer 10 and Internet Explorer 11, with support for Internet Explorer 10 ending on January 31, 2020. There is no longer support for Chrome, Firefox, or any browser using the Mac operating system.”
I agree a native client would be great, although I assume this choice is more because Microsoft wanted it to be multi-platform across iOS, Android, Web, Mac, Linux, Windows, Chromebook e.t.c. and that would either require building it multiple times, or building it in html/js as the lowest common denominator (web).
Welcome to another walled garden messaging service! At least lessons were learned..not.
There seems to be no way to open or see the meetings directly within team. I always have to open my mail, click the link, go to the website, click on open in teams and only then will it open the meeting.
Easily my least favorite chat app, save for those that break basic functionality as their core product (Snapchat). Teams doesn't seem to understand that organization admins might want to see user names in a different format than users. Everyone's name is Last, F., which makes sense from an administrative standpoint but needing to click into someone's profile to figure out who they are gets old _very_ fast.
The only selling point that Teams seems to have is "we're already paying for it."
Company decides the most important thing is to save $20 a month on not paying for slack
It's user interface is unintuitive and messy. I find it difficult to find the context I want.
Search doesn't seem to work.
It takes a long time to load.
When it eventually loads, it pops itself up in front of whatever I've opened and started working on (whilst Teams is busy loading) to take all my keystrokes until I notice the keystrokes aren't showing up in the program I was already using - I've seen at least one person's password entered into a chat session because of Teams "grabbing the front".
And, finally, Teams has taken the initiative to redefine "full screen" such that even that unambiguous terminology is now meaningless. Full screen now means "zoom in, just a little bit". Fuck you Teams.
Screen sharing / video conferencing works fine, however. Except the full screen thing, so even the decent bit has a large caveat.
My apologies for the outburst, but I had to get it off my chest. Teams fucking sucks.
Yep. Was in a Teams meeting last week.
Audio mixing is poor compared with Zoom, any background noise on an active microphone will cut out another person speaking.
The controls menu keeps changing. Click on the "raise hand" icon and it disappears, you can't "lower your hand" until it reappears some random time later.
It's not like there are no good examples of what modern user expectations are for searching a body of text....
Search is hard when you don't have lots of training data, data is poorly organized, you have mostly tail queries, and people aren't used to you search engine's quirks. Search results are also bad when you're balancing quality with yield (as in revenue).
Google mostly doesn't have these problems. It has loads of people searching for head queries, so results are continuously being tested to death. Website owners put some effort into making their content accessible to Google with SEO, and people are used to searching with Google, so they've learned a few tricks for less popular queries.
Local search and corporate intranet search have none of that. You're basically whatever Lucene does out-of-the-box.
So this will eventually also apply to macOS, yes.
https://github.com/MicrosoftEdge/WebView2Feedback/issues/131...
https://github.com/MicrosoftEdge/WebView2Feedback/issues/645
When will Firefox do the same? Asking this since many years now.
Just don't understand how MS can mess up simple copy+paste so badly.
They have years of experience in this field. I always keep a Notepad window open - to be able to copy paste properly.
The number of times I've been copying between a terminal and Teams and accidentally started a call is really frustrating.
What tool do you suggest for teams?
I have tens or hundreds of unread slack messages.
I also know people in the Blackberry era who'd call somelne because they hadn't yet replied to a mail they send a whole 5 minutes ago..!
Personally I think the problem is over-rated and wouldn't mind if there was a bit more off topic chat going on in our Slack/Teams.
The main problem that I have with these tools is the increased number of distractions. There is an expectation when using a chat tool that someone will respond promptly, but this rarely is useful for the person that’s receiving the question.
For most knowledge workers, frequent distractions come at a very high cost. Notions that we are good at multitasking are completely false. Encouraging the use of these tools is contrary to the goals of deep intelligent work And in fact can encourage poor planning and time management.
One is that everything gets sorted under the right project subheading. Discussions about Project FooBar end up in a different channel than discussions about Project Blork. The second is that I can just post on the Blork channel and know that everybody currently connected to project Blork will see it. Equally if I'm not actively working on FooBar I can easily ignore everything connected to FooBar, and just scan through what's happening every other day or so. I personally feel it's useful keep an eye on what is happening in projects tangentially related to what I'm working on without being CC:d on every project related email sent, and Slack makes that easy.
Of course all this can be replicated with mailing lists, email filtering, and decent threading support in your mail client, and perhaps that might even be better, but for whatever reason the tools for easily doing this aren't really being pushed. I'm sure you could build some sort of tools on top of email that gives you most of the benefits of Slack but with a slightly less synchronous feel.
For example, if Blork and FooBar Projects are related In a comment that is made in one of the project channels, it is not easy to navigate their relationships in these tools Without explicitly adding tags to refer to the other channels. All these tags then create a spiderweb of useless links for the most part, and the information flow is weird and difficult to follow in many cases. This model can be advantageous for example when referencing checkins or other tickets within comments of a bug/story reporting system. However, bug reporting systems typically have fewer parties involved in the comments, so things don’t get quite as out of hand.
Far be it for me to defend Teams, but one thing it does kind of right is to automatically create a wiki, a project tracking and a file share page in addition to the chat space for each project so that you can, if you want, use the right tool for the job.
That being said I worked at places a decade ago that tried to do the internal bulletin and wiki thing for their projects, and for whatever reason, it never worked anywhere near as well as I've seen Slack work. So while I agree in theory with many of the complaint levied against Slack as a productivity tool, in practice I've yet to see anything work better. But it is also clear that, for whatever reason, I haven't experience many of the time wasting antics that other people seem to be describing.
I can live with some of the missing features:
No noise cancellation
Audio devices are configured via windows sound settings
Can only share full screens and not individual windows
Standard Windows notification sounds and not the Teams sounds.
Maybe missing more otherwise its more or less the same app.
I've installed it as a Chrome App and it has its own window, task bar icon / shortcut and generates notifications.
I'd suggest others to try it out.
I was about to get a second device for teams. Performance has degraded so badly that it's now impossible to pretend to be in a meeting and run an IDE / office apps / factorio at the same time.
At least on Chrome, the Teams screen sharing option summons the Chrome screen sharing dialog, which allows you to select either the whole desktop, individual windows or specific tabs inside the browser. Maybe the limitation is from the browser you are using? (Although I would be very surprised)