In many ways this is a "classic Microsoft" move — take something that works perfectly fine and replace it with something new but completely inferior and often less featureful. They have been doing this in the consumer space for years and inevitably users get upset but move on.
What I doubt they have considered is the number of businesses dragging-and-dropping mails as EML files and working with offline PST folders and relying on various other invisible features daily that will be completely broken by the transition, not to mention that many businesses likely won't be as tolerant of that breakage as the average consumer will.
This is extremely prevalent in my org. With decades of emails saved on the file system and used as evidence of procedural workflow. It’s now getting annoying as different parts of the org are on different clients so these files don’t always open.
There’s no easy equivalent on the web client or Mac client. Print as pdf sort of does the same thing with a durable record of the email, but takes many more clicks and seconds.
Comically, the people I know who just print out emails and physically file them will be the only ones with real records in years time.
I know there are ways to handle them, but it's still a hassle compared to using a standard format, for which most popular languages have a parser in the stdlib.
> In many ways this is a "classic Microsoft" move — take something that works perfectly fine and replace it with something new but completely inferior and often less featureful.
They’re taking Outlook, which is a Windows-only locally installed piece of software, which can only be extended using Windows-specific APIs.
They’re replacing it with a cross platform codebase which runs on Windows, Mac, Mobile and online in a web-browser (so you can use it on Linux too).
This new version can be extended using web-technology, implemented however you like using whatever language you like, which will not just work on Windows, but on all platform targets (Windows, Mac, mobile, web) seamlessly in a single code base.
Yes. Some features and extension points are going away.
But let’s not pretend we’re getting nothing in return. This is a massive improvement for developers.
Disclaimer: responsible for Outlook addons in company I work for. When applicable, I greatly prefer the new model.
For me it means I’m able to have the same flows and capabilities available regardless of platform or “terminal” I’m using and not have to depend on a particular machine, OS or Outlook “installation”.
There are use-cases which are less supported, like dealing with EML-files, which I too consider a notable loss. Hopefully they manage to bring that back.
> But let’s not pretend we’re getting nothing in return. This is a massive improvement for developers.
If you mean developer end users: those are either by company policy tied to use Windows because corporate antimalware like SEP, Zscaler or WDATP can be deployed and managed remote - or they could just use the web mail and pin that to their desktop as a native app. The “new Outlook” is just a web app, really.
As one simple example among many ways in which the new outlook is inferior, you can't (as for as I can tell and I really have tried) add "message type" as a column. So you can never do the thing which I used to do all the time in classic outlook when processing a full inbox where you click on the message type column, get all the calendar invites in one spot, process them all quickly as a chunk, then go back to processing mail. No. Some pm in microsoft knows better than you. Having that feature would only confuse, so it's been removed.
What I doubt they have considered is the number of businesses dragging-and-dropping mails as EML files and working with offline PST folders and relying on various other invisible features daily that will be completely broken by the transition, not to mention that many businesses likely won't be as tolerant of that breakage as the average consumer will.