A closer look at apps for Outlook

Rolando has already given an overview of how apps for Office work, so today I'm going to drill into how apps for Office run within Outlook. Apps for Outlook, or "mail apps" as they are sometimes called in our developer documentation, are apps for Office that are optimized for running in Outlook against mail and calendaring information. We have built far too much for me to cover everything in detail in one post, so today I will give you an overview of apps for Outlook using some of the exciting apps that our partners built for the Office 2013 Preview, to demonstrate the power of this platform. But first, let me introduce myself.

My name is Jason Henderson and I've been working on Exchange for the last 10 years. I started on the Outlook Web Access team, and then led Exchange Programmability on the Exchange Web Services team, and am now back to the Outlook Web App team where I've been lucky enough to lead a team whose charter combines my two passions—building great end-user experiences and enabling third-party developers to easily extend and enhance the rich experiences we build in Exchange and Outlook with their own unique value.

Let's get started!

Write once, install once, run on desktop, tablet, and phone

The apps for Office platform gives Outlook developers an incredibly powerful tool to help make end users productive across multiple platforms. Developers no longer have to learn multiple technologies to target Outlook on different platforms. Now, a single HTML5 app for Outlook can run in the Outlook rich client and Outlook Web App on Mac, PC, and iOS using the same code.

It has always been very difficult, if not impossible, for developers to extend the mail clients on most mobile phones and tablets, yet there are many incredibly compelling scenarios for integrating third-party information with mobile mail applications. With apps for Outlook support in the Outlook Web App experience on iOS, we are now making it very simple to create an app that is available to a mobile worker in the context of their work email. Simply create an app for Outlook, modify your user experience to be touch-friendly, and publish the app just like you would for Outlook or Outlook Web App, making sure to specify an entry point for the phone form factor in the manifest. Your app will now show up when your users browse to the Outlook Web App experience on the phone, simple as that.

The TakeNote app from MessageWare on Outlook Web App running on a desktop

The TakeNote app from MessageWare on Outlook Web App running on a tablet

The TakeNote app from MessageWare on Outlook Web App running on a mobile phone

All in context

We know that Information workers spend much of their day switching between Outlook and other line-of-business systems, websites, and applications, while consumers spend much of their time switching between Outlook and consumer services like mapping services, or photo-sharing or social media sites. The goal of apps for Outlook is to put third-party services at the fingertips of information workers, when and where it helps them to be most efficient. The power of this model is pretty exciting when you start to think about it. Try asking yourself how much more productive you would be today if every application that you use on a daily basis were intelligently integrated with Outlook.

A great example of bringing context together with a service is the SageOne app. This app displays real-time information like account balance or invoice status, which is pulled directly from the SageOne service for the sender of a given email message. Normally, a query from a customer about their account balance would require switching into another application and copy/pasting sender identity into the system. Sage uses the ability to retrieve the sender email address to prepopulate their app with the information that is most likely to be useful to the app user, to eliminate context switches and reduce user interaction to a single click.

Right time and right place

A key design tenet for Outlook and Outlook Web App in the Office 2013 Preview release was to create a clean user interface where information is easily accessible to users, but does not distract them from focusing on their email. Apps for Outlook were designed from the ground up to be right there when users need them, and hidden from view when they aren't useful. To enable this, we built support for contextual activation into the platform. Contextual activation enables developers to declare specific criteria for when an app should activate.

It has been exciting to see our partners leverage contextual activation to ensure that their apps show up in exactly the right place at the right time. The Harmon.ie and DocuSign apps use attachment-activation criteria to show up only when there is a document that can be DocuSigned or uploaded to SharePoint by Harmon.ie. Similarly, the Elance app shows up only when an email discusses technologies that are potential matches for Elance freelance developers. The LiquidSpace, Twitter by PowerInbox, and Groupon by PowerInbox apps also have contextual activation characteristics and are triggered either by custom regular expressions running against the message or by entities extracted natively from the message, such as addresses or meeting suggestions in the message body.

Developers of mail apps can create custom rules that trigger on message type, patterns in the subject or message body, or patterns in the sender name. We also have support for several "out-of-the-box" extractors built into Exchange by our Natural Language Group. These built-in extractors include US Postal Addresses, US phone numbers, email addresses, URLs, action item suggestions, and meeting suggestions. All of our built-in extractors are currently US English–only, but we are working hard to expand to other locales. Specifying the activation criteria is as easy as defining a regular expression or, in the case of our built-in extractors, simply specifying the type in the manifest will cause your app to activate. The code below shows how to specify for an app to activate on a US phone number using the built in phone number extractor.

<Rule xsi:type="ItemHasKnownEntity" EntityType="PhoneNumber"/>

In our first release, apps for Outlook can activate on the read message form of mail and on the read appointment calendar form for both Outlook and Outlook Web App. The app bar is designed to be highly visible and yet not detract from the overall user experience. We conducted multiple usability studies and worked closely with our design team to find the optimal placement, coloring, and shape of the bar. We think we have achieved the right balance of end-user visibility while maintaining visual simplicity, but we would love to hear what you think!

Rich and easy-to-use mail and calendaring APIs

The core of the apps for Office platform is the powerful JavaScript API for Office. Within the common JavaScript API for Office object model, we built a powerful set of APIs specific to mail apps for interacting with mail items, calendar items, and Exchange Web Services. These APIs enable rich access to the mail on which the user activates the app, and enable direct user interface interaction like replying to an email message.

This is the first platform and API to enable developers to write a single application that gives access to message properties like subject, body, sender, recipients, meeting organizer, meeting locations, and meeting time, while using exactly the same code in both Outlook and Outlook Web App in the Office 2013 release. In addition to giving access to message properties, the API allows developers to initiate the mail reply form and the compose new meeting form with dynamically generated data. A great example of this API in action is the LiquidSpace app for Outlook that detects when a user is suggesting a meeting and gives them the ability to quickly schedule a meeting place at one of the thousands of venues LiquidSpace manages, and then add it to their calendar. In the following images, you can see that the same code prepopulates and launches either the Outlook or the Outlook Web App meeting compose form, depending on which application the app is running in.

While our API is rich, it is not as rich as the Outlook Object Model, which has been built and extended over multiple releases. We will close some of the gaps with the Outlook Object Model, and MAPI, in future releases. But, we are also working hard to ensure that apps are not broken by newer versions of Office and that apps work seamlessly with the same code on both Outlook and Outlook Web App. That vision requires us to think deeply about every method we introduce; sometimes we will make the hard decision not to support scenarios that are not aligned with the "write once-run everywhere" and backward/forward compatibility vision.

Here is a quick list of the scenarios that the JavaScript API for Office supports in Office 2013 Preview:

Read the most commonly requested properties from a message, meeting request, or appointment

Prepopulate and launch a reply or reply-all form for the current message

Prepopulate and launch a new appointment/meeting form

Request an identity token for use with single sign-on

Issue Exchange Web Services requests

Save custom properties on an item

Save custom properties on a per-app basis

Access user language and time zone

Note that access to the Exchange Web Services through the JavaScript APIs are limited to administrator-installed apps, and that only a subset of Exchange Web Services methods are allowed.

Cloud deployment and one-click management

Another key goal we had for apps for Outlook was to vastly simplify the deployment and management story. Common to all applications that support apps for Office is the ability to install apps quickly and safely from the Office Store directly into Office clients and servers. By default, apps for Outlook can be installed by any user running Outlook 2013 or Outlook Web App against Exchange Server 2013.

The new administrative management page for apps makes it possible to install and enable an app for all users in your organization with just a couple of clicks. Previously, this would have required deploying bits manually to Client Access Servers, or sending out updates to Outlook. We think this is quite an improvement!

Apps for Outlook are hosted in the cloud and only an XML manifest is installed into a user's mailbox for end-user installed apps or into an organization mailbox for apps installed by administrators. This model makes upgrades easy and immediate—just upgrade the code on the server hosting the app and instantly all clients will receive the new code. Installing apps into a mailbox enables any device or application that accesses an app to support apps for Outlook. This single repository also gives us a mechanism to roam settings between clients. So, if you are running Outlook, and you install the LinkedIn mail app, and then switch over to Outlook Web App—the app will automatically show up and be ready to use. In fact, because LinkedIn supports our identity token, you will not need to log in again even if you move to another machine.

We have taken many precautions to ensure that end-user information and organization information is protected, and that the user and organization are always in control of the information that they are sharing. One example of this philosophy is that only administrators can install apps that access Exchange Web Services and apps that are hosted any place other than the Office Store. Administrators can also disable apps for Outlook for their organization or leave apps for Outlook enabled but disable end-user ability to install apps. For RTM of Exchange 2013, we expose the ability for an administrator to install an app and make it available, or hide it from an end user in the Exchange Admin Center user interface. Additional functionality, such as the ability for an administrator to install an app for individual users, or force the app to show up in Outlook and Outlook Web App for a set of users, is also possible via the command line.

Friction-free development with Visual Studio

The Visual Studio team has done an amazing job building an incredible tooling story for the apps for Office platform. In a couple of easy steps, a developer can create a new mail app project, write code, provision the app into an Exchange mailbox, and then launch Outlook or Outlook Web App under the full Visual Studio debugger. It is pretty amazing stuff, and because of the way they architected their tools, the same experience is also available from their web-based development suite, the "Napa" Office 365 Development Tools.

Find and install apps as easy as 1, 2, 3

Finding and installing add-ins for Outlook has long been a time-consuming and risky process. There was no single directory of add-ins available, add-ins often brought performance problems with them, and brought a plethora of security dialogs to navigate as they were downloaded and installed. Installing add-ins for Outlook Web App was even worse, it required copying bits directly onto production Exchange Servers!

Brand new in Office 2013 Preview is an incredibly simple way to make apps easy and safe for users to find and install—the Office Store. The Office Store is accessible from Outlook and Outlook Web App so all users can see the apps that are available, quickly see details about the apps—and install those apps quickly and simply.

It is now incredibly easy to get a huge audience of users to see your apps. All you have to do is develop an app for Outlook and publish it through our Dashboard in the Apps for Office and SharePoint Developer Center. Anyone can sign up to submit an app, and we encourage everyone who has a great idea for an app to do it today.

Now, go try apps for Outlook yourself

The Visual Studio tooling work combined with our Office 365 Developer Tenant offering make it easier than ever before to get started building apps against Exchange. If you ever thought it was too hard to get started coding against Outlook or Exchange, check out dev.office.com and see how much easier it is to get set up with a test O365 Exchange environment and Visual Studio.

After reading this post, I hope you are as excited about apps for Office as I am. We are seeing some great mail apps in the Office Store and are looking forward to many more as we get to RTM. Apps for Outlook require Outlook 2013 or Outlook Web App connected to a mailbox running on Exchange Server 2013. If you haven't downloaded the preview of Outlook and tried it against Office 365 yet, go give it a try and then install some apps and give us your feedback through comments to this blog or the apps for Office forums. If you are a partner with an add-in for Outlook—take a look at our platform and think about how you might port your add-in to this model, or maybe build a completely new scenario.

We have many great resources for developing mail apps for Outlook on MSDN. Take a look, try building an app, and if you don't see what you need, let us know. Also, stay tuned to this blog where we will have some more posts shortly to drill into the API, activation, security, and management in more detail. We hope you are as excited about mail apps for Outlook as we are, and hope to see your app up in the Office Store soon!