Killing VBA in Outlook: Reduced Functionality is the Whole Point

In case you haven't heard, "Classic" Outlook is being replaced:

Microsoft is currently working on the so-called New Outlook that is no longer based on COM. This means that the traditional object model, the programmability and the automation of Outlook from other Windows applications such as Access will be lost.

Surely that's Crazy Talk, right?

Things You Should Never Do

In the words of former Excel program manager, Joel Spolsky, Microsoft is in the process of committing "the single worst strategic mistake that any software company can make:

"They decided to rewrite the code from scratch."

Why is this generally such a bad idea?

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.

The Status Quo: Four Outlooks

To be fair to Microsoft, they're not exactly committing Spolsky's "worst strategic mistake."

In his formulation, you stop progress on an existing product to build its exact replacement.  

In the case of Outlook, Microsoft has built three (four?) different products over the years, serving three (or four) different environments:

• Desktop Outlook
• Outlook Web Application (OWA)
• Outlook Mobile
• (Desktop Outlook for Mac)

There are pros and cons to this approach:

Pros

• Each codebase takes advantage of (and works within the constraints of) its associated environment: Desktop has fast performance and tight OS integration; OWA works with the stateless nature of the web; Mobile is optimized for touch UI
• Desktop Outlook benefits from decades of iterative improvements
• Each codebase provides native programmability and integration APIs: Desktop supports COM/VBA; OWA has JavaScript-based web add-ins; Mobile has mobile...stuff (I presume; I'm not a mobile app developer)

Cons

• Maintaining four separate code bases requires roughly four times as many developers
• Keeping feature parity requires coordination among teams (and some features don't translate well to some environments)
• Younger Microsoft developers loathe desktop development (generally) and COM/VBA (specifically)

The above pros and cons are tilted heavily in favor of end-user experience at the expense of developer efficiency.  In short, the current status quo is customer-focused.

One Outlook to Rule Them All

In 2020, Microsoft looked at the Outlook landscape and said, Enough!

Maintaining four separate code bases is madness.  We need to consolidate them into one single Outlook code base that we will call, 'One Outlook.'

Microsoft One Outlook looks like a worthy goal and one that could find great popularity across multiple platforms. And yet, the devil will be in the details. In its post, Windows Central admits Microsoft could change its plans between now and 2022. Assuming things do run smoothly and a universal Outlook app appears next year, perhaps Microsoft will try the same thing with other apps in its library such as Word, Excel, and PowerPoint.

I'm not so sure things have "run smoothly" to this point.  

And yet, I expect Microsoft to continue replacing its "legacy" Office applications–from which it was able to generate enough revenue to fund its Cloud and AI R&D initiatives–with underwhelming web-based doppelgängers in a desperate attempt to cede its desktop Office suite dominance to Google's own cloud offerings.

With that in mind, let's consider the pros and cons of "New" Outlook:

Pros

• One code base to maintain instead of four
• Feature parity across all platforms

Cons

• All the downsides of a web app coming soon to a desktop near you!
• Custom add-ins get to be rewritten in a different language with fewer capabilities and no added value to the business
• EITHER: Sub-optimal UX on some platforms
• OR: Four different UX implementations (but inside a single code base at least, so...win??)

The above pros and cons are tilted heavily in favor of developer efficiency at the expense of end-user experience.  In short, Microsoft's utopian vision for Outlook is company-focused.

New Outlook: A Suckier Version of Classic Outlook

OWA is a great web application.

But it would make a crappy desktop application.

And yet that appears to be Microsoft's exact plan:

• Take the existing web app
• Wrap it inside a WebView2 control
• Apply a thin veneer in the form of a desktop window
• Call it "New Outlook"

When I've had to use the web app, I've always found it to be a very pleasant experience.  

But there's a reason I use the desktop application in my day-to-day work:

• It packs a lot more functionality into the screen real estate it occupies
• I can easily script it using VBA by simply pressing [Alt] + [F11]
• It's easy to automate from Word, Excel, and Access via its COM interface

This slashdot comment sums up the situation nicely:

I'm told the app will feature native OS integrations with support for things like offline storage, share targets, notifications, and more.

Uhm, so...all things that current iterations already do? They're not making a very good case for this, except to make it seem like Microsoft is trying to streamline their code. This isn't a bad thing, but it is something that benefits Microsoft and doesn't benefit end users who leverage existing functionality.

Office Web Add-ins: A Suckier Version of COM Add-ins

Not all COM add-in functionality is available via Outlook web add-ins:

Supported scenarios in Outlook web add-ins
The development of the Outlook JavaScript API used by Outlook web add-ins is focused on closing the gap on scenarios that are only supported by VSTO and COM add-in solutions.

The above comment is a true example of the oft-misunderstood concept of an "exception that proves the rule."  In this case, the "exception" is the explicit list of "supported scenarios" for web add-ins.  This exception proves the rule that not all COM add-in scenarios are supported with Outlook web add-ins.

After providing a list of supported scenarios, Microsoft gives you an opportunity to vent your frustrations into the void provide product feedback that will absolutely be read and incorporated into the development roadmap and definitely not ignored or unceremoniously deleted before another human being ever lays eyes on it:

There are various possibilities for extending the Outlook functionality through add-ins. If your VSTO or COM add-in solution doesn't quite fit any of the scenarios in the table, complete the survey to share your scenario.

But wait! There are more limitations:

Web Add-ins only work with Microsoft accounts:

While you can add non-Microsoft mail accounts, such as Gmail, to the new Outlook on Windows, you can only use Outlook add-ins with a Microsoft account.

But wait! There are more limitations:

Web Add-ins require an active internet connection:

Your web application needs to be hosted on a web server, or web hosting service, such as Microsoft Azure.

On the bright side, you can download and binge watch your favorite TV show guilt-free instead of getting actual work done on your next cross-country flight.

But wait! There are more limitations:

Web Add-ins run in a restricted sandbox environment:

COM add-ins can manipulate Outlook in many ways that often leads to instability and crashes in Outlook. To ensure Outlook is more stable and robust, web add-ins provide a sandbox environment for add-ins to operate in and have checks and balances in place.

Now, to be fair, this DOES provide a more stable and secure environment than granting full access to the application and operating system, as one gets with a COM add-in.  

But why stop there?

For a mere 68 cents 73 cents, you can use a messaging application that will NEVER lead to application or operating system instability.

But wait! There are more limitations:

You can't move or copy items between accounts:

The new Outlook doesn't currently support functionality that enables users to move or copy items between accounts, including:

• Move or copy item between accounts
• Reply or forward message from a different account
• Attach files from document/file storage from a different account

Yes, this is an important security feature for enterprises that need to avoid comingling data among accounts.  It's also another loss of functionality if you have COM add-ins that currently work with multiple accounts simultaneously.

Perhaps Microsoft Will Reconsider?

Erm, no:

We want to be clear that COM add-ins are not going to be supported in the new Outlook for Windows.

Here's a transcript of the key section of the video (lightly edited for readability and grammatical correctness):

[Margie Clinton]: Another top question that is coming up and [people] wanting to hear about is around add-in support. We want to be clear that COM add-ins are not going to be supported in the new Outlook for Windows. In many ways, these don't work cross-platform. They can be a source of some reliability issues that come forward with that.

We actually have what can be a much more extensible platform with the web add-ins. That is where we're working on getting that delivered, and it's already delivered. We are ever-expanding the capabilities available on the web add-in platform, as well as working with third parties (ISVs) to get the add-ins they have to ensure they are supported on the web add-in platform.

We know that many customers will have line-of-business apps or ones that they've built for themselves. If you have more examples, reach out to us. The extensibility team that works on this is very open and highly driven by customer engagement.

[Robert Novitskey]: If I can just add, we've had people say, "Can't you just add COM add-in support to the new Outlook?" From the standpoint of the team that builds this, we find that most of the really great add-ins aren't just COM add-ins. They integrate with the MAPI subsystem and other parts of the machine. They do things with our visual tree, injecting themselves into it, which ends up being part of the instability mentioned earlier, using our object model.

Rebuilding all of that is rebuilding classic Outlook.

We are really trying to look at this forward-looking, web-based add-in model as one that can be great for the new Outlook for Windows and also work cross-platform.

Moral of the Story: Reduced Functionality is the WHOLE POINT!

Most of the posts on various forums and comment sections lamenting the exclusion of COM and VBA from "New Outlook" take the following form:

Microsoft CANNOT switch to New Outlook until we get full COM add-in feature parity!!!

That might happen if Microsoft actually cared about feature parity between "Classic" Outlook and "New" Outlook.  

Notwithstanding Microsoft's token calls for user feedback, though, Novitskey's statement above...

[W]e find that most of the really great add-ins aren't just COM add-ins. They integrate with the MAPI subsystem and other parts of the machine. They do things with our visual tree, injecting themselves into it, which ends up being part of the instability mentioned earlier, using our object model.

Rebuilding all of that is rebuilding classic Outlook.

...lends itself to only one logical conclusion:

The New Outlook team has no intention of achieving feature parity with Classic Outlook.

Consider yourself warned.

Cover image generated by DALL-E-3.