Written by Tatyana Shestopalova, Technical Product Manager
In my last post, I wrote about how browser extensions can be one of the fastest paths to ubiquity for new software.
For example, the Chrome extension we built displays information from our software directly inside of Gmail’s HTML — creating an experience that enables our customers to use our software without changing anything about their existing workflow. However, our extension only supports customers that use Chrome — specifically, Gmail on Chrome. While Gmail on Chrome is a popular email choice among our customers, a large percentage of our customer base emails with Outlook. This year, we’re expanding our products to include an Outlook365 add-in.
Two technologies exist for building Office products: Visual Studio Tools for Office (“VSTO”, uses .NET or C#) and JavaScript API. These technologies have absolutely nothing in common, making it impossible to switch between them without completely starting over. Essentially, we knew that once we decided on a technology, we wouldn’t (couldn’t) go back.
I did a bunch of reading and also called on friends who work at Microsoft to help us determine which path to take. Early on, things didn’t look great for JS API. It’s a newer (read: buggier) technology, has a smaller development community, and has less support than VSTO — mostly because VSTO has been around since the internet stone age. But in the end, the JavaScript API prevailed as the right choice for us to make. Here’s why:
1. Customer impact
Roughly 10% of our customers that use Outlook run Office on Mac. VSTO add-ins are based on a technology that does not exist on Macs. Choosing to build with VSTO would mean choosing to never support customers that use Outlook on Mac (without building an add-in with JavaScript API, anyway). Additionally, a VSTO add-in supports only one Office product at a time, while one JavaScript API add-in can support many Office products across various operating systems. With one codebase, we already support Outlook on Mac, Outlook on PC, and Outlook on the web.
2. Distribution
I’ve come to understand that many software teams that choose to build VSTO products are part of an in-house IT team that has direct control over installing their solutions via .exe files across all of the Windows machines where they’re needed. Without the ability to physically access our customer’s computers to run an install file, we could hypothetically distribute our VSTO product by hosting a 1-click installer button somewhere online, mailing our customers a CD with the install file (the documentation really did recommend this), or publishing updates through the Windows Installer.
Given the fact that we push new code to production multiple times every day, none of these options seemed possible for us. We didn’t want to hound our customers to download new versions of our VSTO add-in, and let’s face it — how often do we all ignore the Windows Installer? Building with JavaScript API allows us to distribute our product through the Microsoft AppSource store, and the store propagates updates automatically.
3. The technology
We were initially concerned that Microsoft’s JavaScript API would output a C# codebase, which is inherently scary because frameworks can compile code in unexpected ways (just ask anyone who has used React Native to build iOS and Android apps). This fear was quickly debunked once we learned that JavaScript API add-ins have absolutely nothing to do with VSTO add-ins.
We also learned that today’s version of the Office.js library has all of the support we would need to fully replicate the capabilities of our existing Chrome extension for Gmail (e.g. determine the sender of a given email). Plus, we can host the HTML, CSS, and JavaScript for our Outlook add-in on the Python servers that host our web app, so code changes to anything other than the manifest.xml file (which lives in the Microsoft AppSource store) are live as soon as we restart our servers (multiple times every day).
4. The team
Finally, if we were to build a VSTO product, we would need to either hire a .NET/C# engineer or task one of our existing engineers (likely me) with learning how to build with this technology. The required skill set for engineers to build with JavaScript API includes JavaScript, HTML, and CSS. Every engineer on the 4Degrees team has these skills today.
Ultimately, the two main reasons we chose the JavaScript API route to build our Outlook add-in were to support macOS customers and to distribute updates automatically. The API also seemed straightforward to work with but keep on the lookout for my next post where I’ll list some of the headaches I experienced early on while working with Microsoft’s JavaScript API for Office. If you’re building an add-in for Office 365, I would love to hear your comments about which technology choice made sense for you.
If you’d like to try out the 4Degrees Outlook add-in that’s mentioned in this article, you download it for free from the Microsoft AppSource store.
.png)
